On 30/03/2010, Phil Steitz <phil.ste...@gmail.com> wrote: > Luc Maisonobe wrote: > > Jörg Schaible a écrit : > >> Hi Dimitri, > >> > >> Dimitri Pourbaix wrote: > >> > >>> Hi, > >>> > >>>> I checked one of the tests and I assume that all of the above are JUnit > >>>> 4.x tests ...? My Ant/lib contains only JUnit 3.8.x. Should JUnit 4.x be > >>>> provided with the build or with Ant? > >>> When I was updating SVD, I noticed that parts of the tests were 3.x > syntax > >>> whereas other 4.x (way easier to use I think). I would advocate for the > >>> generalisation of Junit 4.x tests whenever possible. > >> Well, I think no one is against this, unless somebody does the work ;-) > >> However, this is IMHO no requirement especially now for the release. > > > > I think it would be better to update to latest Junit. I'll do it after > > 2.1 is out. It will take some time as we have more than 2000 tests now. > > > > I am certainly not going to stand in the way of this if you want to > burn the cycles to do it, but I really see little point in it. We > should be able to fix whatever is wrong with the Ant build to make > sure that it recognizes both sorts of tests.
+1 There are some advantages to JUnit4 - e.g. automatic exception checking and timeouts - but for most simple tests JUnit3 is good enough. Luckily one can mix the two (but please not in the same class!). > <side-rant>The whole @test nonsense seems *really* silly to me. I > kiss my lucky stars that no one got the bright idea to do @getter > and @setter. There is nothing wrong with coding by convention and > when there *is* a convention, mucking things up by adding > annotations that impact runtime performance is, well...silly. > </side-rant> > > > Luc > > > >> - Jörg > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
