[Hawkular-dev] Assertj framework

Joel Takvorian jtakvori at redhat.com
Wed Sep 7 03:42:37 EDT 2016


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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160907/3d581aec/attachment.html 


More information about the hawkular-dev mailing list