Less discarding of test failure throwables

[dubinsky]

... and more propagating thereof.

On one end, it seems a shame to discard information that we have.

On the other end, receiver of the sbt.testing.Event - in my case, Gradle plugin for multi-backend Scala - has to provide a throwable to Gradle, which requires one to accompany a test failure, and if it is not propagated by the test framework, a fake throwable has to be concocted (ugh).

This change makes the ends meet ;)

[zainab-ali]

Suggested change

	failures.map(_.source).find(_.isDefined).flatten
	failures.collectFirst {
	caseResult.Failure(_, Some(cause), _) => cause
	}

[dubinsky]

done, thanks!

[zainab-ali]

Thanks!

My only concern (which doesn't need to be addressed) is that we're only taking the first failure and discarding others. If this ends up being a problem, we could define CompositeFailure exception that aggregates the causes.

[dubinsky]

My only concern (which doesn't need to be addressed) is that we're only taking the first failure and discarding others.

Yes, this asymmetricity bothers me too; but for test failure reporting, one - any one! - is better than none...

[Baccata]

I think this is good enough for now, in the sense that it makes the library better for a rather niche usecase without impacting the majority.

[dubinsky]

Reporting the cause of the test failure does not seem like an niche use case to me; do I need to do anything for this to get merged?
Thank you!

[dubinsky]

A little more context: there is no throwable in the sbt.testing.Event reporting failure of pureTest("failure"){ expect(0 == 1) }; I suspect that the cause is that that such singular-seeming failures are packaged as Result.Failures (plural) and not Result.Failure (singular); if that is true, in addition to the proposed change, mistaken packaging of a single failure into Result.Failures (plural) should be fixed - by you ;)

Thanks!

[Baccata]

if that is true, in addition to the proposed change, mistaken packaging of a single failure into Result.Failures

That is what I meant. My point is that if mistake there is, you're the first reporter in years being noticeably impacted by it, hence the "niche" denomination. I presume the use of Gradle is what led for this to be noticed, and Gradle is a somewhat niche build-tool in the Scala community. Didn't mean anything more by it, providing a mitigation is indeed important.

We can start with the mitigation you implemented in this PR and take the time to assess what should be done for a more proper fix.

[dubinsky]

Thanks!

[dubinsky]

We can start with the mitigation you implemented in this PR and take the time to assess what should be done for a more proper fix.

@Baccata I think #186 is what should be done ;)