Ah ha! Since I wrote the code for the run option, I can tell you
why the results vary:
1) I never even considered nested classes as a use case
2) We didn't have generics at the time.
So the results you are seeing with cases B and C are
actually bugs - at least in terms of what the option
was intended to do.
That said, I agree with your analysis. It makes more
sense to treat a nested class as a member of the class
in question. I would not want to do this piecemeal,
however. I think we should treat things consistently
for the console and Gui runners.
So far we have:
* Naming of tests in the console test case labels
* Naming of tests in the Gui
* Hierarchical display of inner classes in the Gui
* Use with the /run option
* By extension, use with the /fixture option
Any thing else?
Charlie
that I never even considered the case of nested classes, so
the results you see with generics are accidents of the
implementation... as follows...
If the value you pass to the run option is the name of
a type, then that type is used as a fixture. If not, it
is assumed to be a namespace and we look for all classes
whose fullname has that value as a prefix.