I haven’t got any objections. This is already the case with arquillian tests, which rely on junit.
Cheers, On 14 Mar 2014, at 16:55, Sanne Grinovero <[email protected]> wrote: > TLDR: I'm banning TestNG from the Query modules, and this will affect > the parent poms. > -- > > I needed to run some quick experiment rounds in Query, but *some* > tests fail, and I simply want to know which ones to evaluate some > approaches. > > But I can't get to know the full list easily, as failing a test in our > current testing framework apparently implies you'll be leaking > resources, and the suite slowly grinds to a slow death running out of > resources. > > The problem in this, is when I need a quick evaluation which is > blocking other people in other teams, embarking in such witch hunting > is not an option; while I'm co-responsible of some of the embarassing > ugliness in our test's resource handling, I do primarily blame to > tooling rather than ourselves: especially TestNG's ridiculously > unreliable handling of shutdown hooks - and have enough of it. > Compared to that, the resource handling of JUnit is extremely handy > and reliable: requires a bit more coding as it provides less features > than TestNG, but can be relied on. > I can't really afford spending time to migrate all tests to JUnit > today, but I will start doing so in smaller iterations. > > Now one problem is that TestNG, and several other dependencies, are > included by default in the parent classpath. Having a set of default > dependencies - even just in provided or test mode - forcefully > provided to all modules has created some other trouble too; for > example I really don't want the slf4j logger in my classpath as it has > hidden problems in classpath structure of our own modules. > > ## -> Would you all be ok if I move the dependencies to the dependency > management section? > (You can all use TestNG in your own modules if you want, but please > allow me to opt out) > > That implies each module will have to explicitly pick what it needs; I > consider that a good thing as explicit is good, and getting utilities > on classpath from out-of-the-blue is confusing. For example, moving > just one dependency yesterday I could figure out that the migration to > Netty4 was actually incomplete and some tests where still using > Netty3. I consider that a proof of a more healthy structure. > > Sanne > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño [email protected] twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
