Hello, and excuse me for the late reply, I didn't realize until now that the online archive of the mailing list can have more than one page per month, and since my original email didn't show up on the first page, I was wondering whether it ever went through (I didn't subscribe to the list, which I now regret as I am editing the header fields of this email manually, hoping that I do it correctly and that the message will be attributed to the correct thread).
Regarding the point about a potential mess of multiple JUnit versions: JUnit 5 seems to provide a "Vintage" test engine to support the execution of JUnit 3 and 4 tests alongside JUnit 5 tests. If this Vintage test engine is added as a dependency in a Maven project in addition to JUnit 4, then Maven will be able to run JUnit 4 tests on the Vintage engine whilst running JUnit 5 tests on the Jupiter engine from JUnit 5 (provided the Jupiter engine is added as a dependency). See https://junit.org/junit5/docs/current/user-guide/#running-tests-build-maven from the JUnit 5 user guide. I also tried it without the Vintage engine, i.e. only JUnit 4 and the Jupiter engine, but then, Maven would either run only the JUnit 4 tests or only the JUnit 5 tests, or sometimes no tests at all, who knows why. But with the Vintage engine, new tests can be written in JUnit 5 without requiring all existing JUnit 4 tests to be migrated to JUnit 5 at once, because, as far as I understand it, JUnit 5 tests will be run by the Jupiter engine, JUnit 4 tests can be run by the Vintage engine until they are migrated to JUnit 5, and the JUnit 4 dependency, it seems to me, is only needed for compiling the JUnit 4 tests, but not for running them. ------------------------------------------ From Gilles Sadowski <gillese...@gmail.com> Subject Re: Proposal to introduce JUnit 5 in commons-numbers Date Sat, 25 May 2019 10:11:43 GMT Hi. Le ven. 24 mai 2019 à 06:01, Eitan Adler <li...@eitanadler.com> a écrit :
(please make sure to CC me on replies) +1 on this. One thing I'd like for us to avoid a mess of different junit versions making it difficult to know which runner will be executing the class. It would be great if we did a complete conversion and not just introduced new syntax.
+1
I've actually done this before on a largish Java project from JUnit3/4 to 5. It isn't hard, just a fair amount of mechanical code changes.
Patch/PR welcome. Regards, Gilles
On Wed, 22 May 2019 at 15:30, Eric Barnhill <ericbarnh...@gmail.com> wrote: > +1 > > On Wed, May 22, 2019 at 3:15 PM Gilles Sadowski <gillese...@gmail.com> > wrote: > > > Hi. > > > > Le mer. 22 mai 2019 à 18:43, Heinrich Bohne <heinrich.bo...@gmx.at>
a
> > écrit : > > > > > > Right now, commons-numbers is using JUnit 4.12, the last stable version > > > of JUnit 4. As far as I am aware, there is no explicit syntax in JUnit > > > 4.12 for testing whether an exception is thrown apart from either using > > > the deprecated class ExpectedException or adding the "expected" > > > parameter to the Test annotation. The problem with the latter approach > > > is that it is impossible to ascertain where exactly in the annotated > > > method the exception is thrown – it could be thrown somewhere > unexpected > > > and the test will still pass. Besides, when testing the same exception > > > trigger with multiple different inputs, it is impractical to create a > > > separate method for each test case, which would be necessary with both > > > aforementioned approaches. > > > > > > This has led to the creation of constructs where the expected exception > > > is swallowed, which has been deemed undesirable > > > < > > > https://issues.apache.org/jira/browse/NUMBERS-99?focusedCommentId=16843419&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16843419 > > >. > > > Because of this, I propose to add JUnit 5 as a dependency in > > > commons-numbers. JUnit 5 has several "assertThrows" methods that would > > > solve the described dilemma. > > > > +1 > > > > Gilles > >
