BTW groovy tests use junit assertions, so here also we could use assertj if
we want to.
On Wed, Sep 7, 2016 at 9:38 AM, Joel Takvorian <jtakvori(a)redhat.com> wrote:
> never be sure if it's "expected, actual" or
"actual, expected".
It's an interesting point, because the assertj way is precisely solving
this issue with its english-like fluent writing : "Assert that <something>
[is / contains / matches / whatever] <some other thing>". It's quite
clear
in this sentence that the subject is <actual>, complement is <expected>.
And you never have to worry about it anymore.
About the testing libraries, if we try to analyse that:
JUnit: can't get rid of it, however the JUnit assertions could eventually
be gradually replaced with the ones of the preferred framework if we want
absolute homogeneity (but do we really want it?)
TestNG: same as above, could be gradually replaced
Mockito: still useful, not overlapping
Testing in Groovy: my guess is that it was interesting to use groovy for
on the fly objects declaration, maybe among other benefits. It seems to
suits quite well for integration test, no?
I haven't found the scala tests yet :)
So the overlapping parts are more on JUnit / TestNG, and Assertj if we
come to add it. But comparing to junit/testng, assertj clearly brings nice
facilities as I described above. IMHO there's no need to rewrite every
tests, adopting a new assertion framework can be done just progressively,
without forcing anybody to adopt it right here right now. It's just giving
some more tools that can be very appreciated some day on a particular
situation.