You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If we decide this is worth doing, we will have to take the following things into account.
We should prefer JUnit Jupiter API's assertThrows over the try..fail..catch idiom
We might want to use assertAll over just writing assertions one line after another, so that all potential assertion errors can be gathered and thrown together as one exception for easier debugging.
I'm willing to consider this, but IMO, it's something we can address after 3.0 is released.
I'm more interested in adapting our tests to use Truth for most things, honestly.
Addressing a few of the points (in ignorance of how JUnit 5/Jupiter work, since I haven't used or researched them, just going from your description above):
(2) I have mixed feelings about assertAll. Seems like you might need fewer test runs to uncover all of your errors, but it might be harder to read the outputs.
(3) I think that this is a non-issue: none of our tests have timeouts at the moment (and I wouldn't expect them to need to).
(4) Using Truth should help considerably with these scenarios.
If we decide this is worth doing, we will have to take the following things into account.
assertThrows
over thetry..fail..catch
idiomassertAll
over just writing assertions one line after another, so that all potential assertion errors can be gathered and thrown together as one exception for easier debugging.assertTimeout
orassertTimeoutPreemptively
where we would have used@Test(timeout=...)
or@Rule public Timeout timeout = ...
assertIterableEquals
andassertLinesMatch
where normal collection equality assertions are insufficient.@Rule
s or@Runner
s, we will need to find alternative extensions for JUnit Jupiter/5.The text was updated successfully, but these errors were encountered: