Re: Is Junit5 the way to go?

[Niclas Hedhman]

Personally, I find the AssertJ (and practically all other attempts at this)
less powerful and harder to work with, as the DSL is not necessarily
intuitive, well it isn't for me when writing it, although one can guess
what it means when reading it, but perhaps that is the case for Hamcrest
too for other people. Additionally, if you ONLY know JUnit4, then a subset
of Hamcrest is already included inside the JUnit jar file. In essence, both
AssertJ and Hamcrest was a "solution" to the older JUnit assertion
mechanism.

In AssertJ, there seems to be a "bias" towards creating your own Unit Test
Assertion classes, so that the tests reads more nicely. And in Hamcrest,
the "bias" is towards creating a ever-growing library of generic assertions
independent of the unit tests at hand. IMHO, the former can still be done
in Hamcrest, but I have not seen that, and I have also seldom seen anyone
creating their own AssertJ assertion classes.

Across the Java community, more people are comfortable with Hamcrest than
AssertJ, probably due to Junit's inclusion of some of it.

My recommendation is to use JUnit4 + Hamcrest library + creating PLC4X
specific Matchers (if needed).


I spent this morning changing the AssertJ to Hamcrest across all tests. You
want a PR?
https://github.com/niclash/incubator-plc4x/commit/2080c40c02249db5f5ec0cf0b37b0ea0524de922


Cheers
Niclas



On Sun, Feb 11, 2018 at 5:31 PM, Christofer Dutz 
wrote:

> Hi Nicolas,
>
> While I was at it, I press everything to junit 4 and migrated all junit
> Assert statements with assertj assertions. Do you have any opinion to these
> two options? Hamcrest vs. AssertJ?
>
> Chris
>
> Outlook for Android herunterladen
>
>
>
> Von: Niclas Hedhman
> Gesendet: Sonntag, 11. Februar, 05:17
> Betreff: Re: Is Junit5 the way to go?
> An: dev@plc4x.apache.org
>
>
> 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" 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
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: [VOTE] Switch to JUnit 4 as testing framework

[Christofer Dutz]

Hi All,

so the vote passes with 3 +1 and 1 +0 vote.
I'll now merge my feature branch back to master.

Chris

Am 09.02.18, 00:13 schrieb "Justin Mclean" :

Hi,

Given the issues we’re currently seeing with Junit5 I’m +1 on this. But 
that doesn’t mean we can’t revisit in the future once it’s kinks are worked out.

Thanks,
Justin

Re: Is Junit5 the way to go?

[Christofer Dutz]

Hi Nicolas,

While I was at it, I press everything to junit 4 and migrated all junit Assert 
statements with assertj assertions. Do you have any opinion to these two 
options? Hamcrest vs. AssertJ?

Chris

Outlook for Android herunterladen



Von: Niclas Hedhman
Gesendet: Sonntag, 11. Februar, 05:17
Betreff: Re: Is Junit5 the way to go?
An: dev@plc4x.apache.org


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" 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