>
> Chris
>
> Outlook for Android<https://aka.ms/ghei36> herunterladen
>
>
>
> Von: Niclas Hedhman
> Gesendet: Sonntag, 11. Februar, 05:17
> Betreff: Re: Is Junit5 the way to go?
> An: dev@plc4x.apache.org
>
&g
aden
>
>
>
> 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 cr
sendet: 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 f
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,
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
>
Hi Justin,
thanks for finding that ... guess when porting all these thousands of
statements, I must have missed one or two "replace: ' == ' with ').isEqualTo('"
__
Well the main reason was probably, that I wanted to replace the
"assertTrue(A==B)" with something like "assertEqual(A, B)" as
…but it does make for a good test passing rate :-)
Hi,
BTW any reason you use assertThat form AssertJ rather than the one built into
Junit 4? Just curious no strong views either way.
You might want to fix a couple of your assertThat’s for instance this:
assertThat(tpdu.getTpduCode() == TpduCode.CONNECTION_REQUEST);
Isn’t probably doing what
I just compared the surefire report generated by master with Junit5 with the
one in the feature branch for java4 and
Junit5: Lists 76 Tests
Junit4: Lists 138 Tests
So all the time we have been relying on a test-tool that doesn't really seem to
do its job ... I strongly think we should get rid
Ok ... today Justin pointed out my changes from yesterday caused tests to fail
I tried and had to agree with him ... the code was simply wrong. But I wrote
tests for it and when manually executing the tests in IntelliJ they failed.
As I did a full maven build with tests before committing and
Hi,
> Well the one thing I like with TestNG is the support for parametrized tests.
> With JUnit 4 this sucks greatly and it very easy with TestNG. I do think that
> we need parametrized tests as we do have a lot of options to test.
There are some existing parametrised tests and I've used it in
11 matches
Mail list logo
