Runner should be able to register itself with the Computer

[bechte]

Currently, the resolving strategy of the test runner is very static. The only way for a Runner to participate is via the @RunWith annotation. This is more than fine as long as the runner does only support top-level classes.

Now with the HierarchicalContextRunner (see https://github.com/bechte/junit-hierarchicalcontextrunner), which has more and more stargazers, it's somehow different. This runner supports member classes and uses them to form a context hierarchy, i.e. member classes will inherit all initializations from the outer classes, without having to extend them. This is a great benefit.

Now, when the tests are executed, everything is fine. But when someone restarts a test of a lower hierarchy, then the test tools does not recognize the @RunWith annotation of the top-level class. Instead it tries to run the very most inner-class with the default JUnit4 runner, leading to a "The inner class XYZ is not static."-Exception.

I wish we could have an extension point other that the @RunWith annotation, that allows us to contribute to the way, JUnit resolves the runner, namely, the Computer mechanism should be more extendible.

If that's not possible, maybe we can change the current Computer in such a way, that given a non-static member class, the Computer resolves the top level class and verifies if this class is annotated with @RunWith and uses this runner instead of the default JUnit4 runner, which anyways does not support this kind of classes, at all.

For the latter approach, we would only have to change the current implementation of the AnnotatedBuilder.runnerForClass(Class) method to perform the check within a for-loop (see attached pull request).

What do you think about this change?

[kcooney]

Fixed via #816