fr., 19.11.2010 kl. 12.13 -0800, skrev Rex Hoffman:

Rex, 
 
I don't really see there is any disagreement between what you suggest
and the per-provider strategy. I also agree with your long term goal,
but I want decent migration strategies.

The gap between the features implemented in surefire and the features in
the test frameworks is closing, but unfortunately there is a lot of
tension still. At least with junit 4.8.2 there are a *lot* of issues
that need to be solved somewhere else, and there is quite a lot of stuff
that real projects do that surefire solves nicely. 
 
So we keep a nice migration path by extracting the current stuff into
separate modules that other providers can choose to use or not. Surefire
tries to cater for widely different versions of testing tools. So you
could say that the features in surefire represent the *sum* of all the
missing features in all testing tools, and due to high cohesion in the
(,2.6] implementation it creates bloat. Which is why componentizing
surefire makes sense; it's also an argument for deprecating the
front-controller surefire-plugin.

An upgrade path that starts with "upgrade to junit 4.9 and jdk6" is not
an option. I will happily make the "Zero config" junit/testng plugin
once this base infrastructure is in place, it should be less than 20
lines of clean code once the componentization is done.

But it won't work on *my* projects, at least not with current versions
of junit ;)

Kristian
   



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to