[infinispan-dev] Deprecating parent dependencies & migrating to JUnit

[Galder Zamarreño]

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 <sanne at infinispan.org> 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
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org