Re: Rework runner concept / intellij or eclipse formatter file?

> I think the runner concept is one of the bigger flaws in junit.

I want to defend the runner concept. I think the runner concept was an excellent and very open-minded move by JUnit-4.x. The runner concept clearly separates test-reporting (i.e. names and results of test-runs) and test-execution (what happens when a test runs) as two distinctly different concerns.

There is a default runner to support some generally accepted x-unit concepts. I.e. execution of test-methods that report a fail-or-error result by throwing an exception etc. But the runner concept offers a great opportunity to try out other wild ideas about test-execution as well, e.g. tests that don't have test-methods or exceptions, and have them harnessed as JUnit-tests that can be executed with the regular build-tools and IDEs (such as intellij or eclipse).

I believe you recently commented on such a "wild idea" that was discussed in this forum:
http://tech.groups.yahoo.com/group/junit/message/24368

It would be fairly easy to develop those features in a 3rd-party project and thereafter implement a suitable JUnit-runner, which perhaps could be used like this:

@RunWith(AnnotationDrivenSuiteRunner.class)
@AnnotationDrivenSuite({ Foo.class, Bar.class})
public class Test_annotation_driven_testing_of_methods_in_Foo_and_Bar {}

This way it is possible for everyone to try out the ideas in IDEs and build-tools without the need to install any extra plugins - because to IDEs and build-tools it will all look like regular JUnit-tests.

So even though JUnit primarily supports certain ideas (test-methods, rules etc) on how to test Java software, its runner concept keeps an open door for anyone who thinks differently and wants to try out alternative ideas.

...
> If you want a certain behaviour you need to use a specific runner.
> Often you will want more than just one behaviour. For example you
> may want the spring runner with junit and jparams behaviour.
> Sometimes you will find a way to makr that work. Sometimes you just dont.

As Stephen pointed out there are also rules, which are a better fit for some behaviour, but different rules can still be incompatible. As with everything else it depends on how well the runners and rules are implemented and how they are used. Sometimes rules or runners can be properly combined with a variety of other rules or runners - and sometimes they don't manage to perform in solitude. I have developed CallbackParams, which features a parameterization runner that can be used like this ...

@RunWith(CallbackParamsRunner.class)
@WrappedRunner(SpringJUnit4ClassRunner.class)
public class AParameterizedSpringTest {

... to complement the spring runner or just about any other runner (including many other parameterization runners) with the parameterization-features of CallbackParams. So when you write ...

> A rework of the runner-concept, introducing something like a
> chain for the behaviour-part would be a good idea, i guess.

... I find it a bit bold, because from my point of view the runner concept can work as a pretty good fit for "a chain for the behaviour-part". In the CallbackParams docs I have expressed it in terms of Aspect-Oriented Programming (AOP):
"JUnit's annotation @RunWith exposes a pointcut. The class CallbackParamsRunner acts as an advice for this pointcut by making the necessary modifications to the test-class and then delegates test-execution back to JUnit's built-in Runner implementation or to the specified third-party implementation, which in turn can be regarded as the next advice for the pointcut."

So the runner concept allows CallbackParamsRunner to apply its advice (i.e. additional behaviour) by making byte-code modifications, i.e. a pattern that is also used by many ~real~ AOP-frameworks to apply their advice.

I like to think of rules as other advices that are applied at other pointcuts by JUnit's default runner (but without byte-code modifications). This way runners and rules can form a chain of behaviour by applying advices for different pointcuts.

...
> This could either be achieved by introducing a runner that does
> the work or by introducing this concept deeper into the framework.
> How are your thoughts on this?

Well, I am open for new and clever extension points but why not start by developing it as a 3rd-party project that enforce the new features with a new powerful runner? But you need to do a very good job to make me want to deprecate today's runner concept ...

> It could only work well when introduced to junit
> and the old concept would get marked deprecated as this makes
> runner-providers like spring migrate to the new concept. I would be willing
> to give it a try and implement this if you think its a good idea.

/Henrik



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/junit/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/