(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. 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.
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 > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > -- Eitan Adler
