Adam Murdoch-3 wrote: > > They would be chained, so that you're providing a decorator over the top > of the build-in implementation. >
I got that, but my impression was that I would have to postpone all action until the last call to TestProcessor in order to collect the test classes, and figured that other involved parties (like the parallel test runner) might not like this. Or is there a way to get the list of test classes up-front? Adam Murdoch-3 wrote: > > My assumption is that this hook is something that only a handful of > plugins are going to need to use. And so, in this case, I want minimal > impact on the Test task's API to keep the noise down. I don't want a > bunch of different ways of achieving the same thing. > > I will add something soon. > Great. I don't mind to write a few more lines to achieve my goal. Maybe this will finally justify a Gradle Spock plugin. Adam Murdoch-3 wrote: > > Absolutely. For me personally, I think I would get most value out of > this feature if I could use it with our functional tests, which are > plain JUnit tests and don't use Spock (though maybe they should). > At Smarter Ecommerce (the company I'm working for), Spock + Groovy make an even bigger difference for our higher-level tests, because they tend to be more complex than our unit tests (fixture setup and such). @Stepwise and a few custom extensions also help. We only occasionally rewrite existing tests, but all our new tests are written with Spock, often resulting in siblings for existing JUnit classes. Adam Murdoch-3 wrote: > > Our unit tests are fast enough, particularly with parallel testing and > incremental build, that I don't really care about whether they are > reordered or not. > Class reordering is most effective for slow tests run by the build tool; method reordering can help save a second or two in your IDE, many times a day. Just to let you know, Spock's test reordering is inspired by JUnit's org.junit.experimental.max.MaxCore, which ships with recent versions of JUnit. Might not be of much help to Gradle though, since you seem to integrate with test frameworks at a different (deeper) level. Cheers, Peter -- View this message in context: http://old.nabble.com/Running-test-classes-in-a-custom-order-tp28792765p28886342.html Sent from the gradle-user mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
