The difference between Junit4 and Junit5 are relatively minor from a user's
perspective. The real difference is when creating Runners for special need
systems, such as Spring
So, going with JUnit4 for now is not a bad thing...
But, it seems that there is some legacy that should be scrapped, because it
actually makes a difference.
Avoid the Assert.isEqual(), Assert.isTrue() and so on, and only use the
Hamcrest library for conditions, i.e. assertThat.
The benefit is that one can use (or make) much more complex tests, which
are otherwise ugly to write or report back what is expected.
assertThat( myInteger, equalTo( 15 ) );
assertThat( myCollection, hasItem( "Niclas" ));
assertThat( myCollection, hasItems( "Niclas", "Justin", "Chris" ));
Arbitrarily complex matchers can be made, and give a reasonable error
message when failing.
If I can find some time in the next couple of days, I will take a look and
propose changes...
On Feb 9, 2018 16:35, "Justin Mclean" <justinmcl...@me.com> wrote:
> Hi,
>
> > thanks for finding that ... guess when porting all these thousands of
> statements, I must have missed one or two "replace: ' == ' with
> ').isEqualTo('” __
>
> Yep I can imaging my brain zoning out when doing that :-)
>
> > Well the main reason was probably, that I wanted to replace the
> "assertTrue(A==B)" with something like "assertEqual(A, B)" as this outputs
> the "expected" and the actual "value" and hereby provides a little more
> information than a simple "was false". So I had the option of converting it
> to JUint "Assert.assertEquals" or update it to AssertJ's
> "Assertions.assertThat().isEqualTo()" which I think is a little more
> readable
>
> You know that Junit4 also has a assertThat? It’s has a slightly different
> signature which what threw me when I first looked at the changes.
>
> Thanks,
> Justin
