Fixes #122: Apply filtering consistently

[paulduffin]

This change makes the following changes:

• The list of FrameworkMethod returned from getChildren() is a flat list of subclasses of FrameworkMethod, one per test method. Parameterized methods return a ParameterisedFrameworkMethod, non-parameterized ones return a NonParameterisedFrameworkMethod, if an error occurs during analysis it returns a DeferredErrorFrameworkMethod.
• The ParameterisedFrameworkMethod has a list of child InstanceFrameworkMethod and implements Filterable.

A lot of special code in JUnitParamsRunner has been removed to use the default behavior from ParentRunner/BlockJUnit4ClassRunner. I also removed ParameterisedTestClassRunner and ParameterisedTestMethodRunner which makes the flow a little simpler, it is still a little convoluted.

I added a test to check for consecutive application of Filter instances and fixed a minor issue with naming in TestMethodTest.

It passes all the tests but I do not know whether every aspect of its required behavior was covered by the tests. In particular I am concerned about JUnitParams.flat, ignored tests and changes in the ordering of error conditions.

[woprzech]

Hello, thanks for your PR. We looked through it but we are not sure what goal you're trying to achieve.

1. filter some of generated params test for single method like

@Parameters("a|b|c")
@TestCaseName("{method}_{0}")
public void testMethod(String parameter)

and using filter matching exactly by testMethodName you would like to run only e.g. testMethod_a. So in the example JUnitParams will generate 3 methods

testMethod_a
testMethod_b
testMethod_c

and after filtering you would like to run only

testMethod_a

2. Or maybe you want to achieve something else and we are not on the same page.

Your code generates better description for each test (description contains also parameters) but it does not solve problem described in 1)

[paulduffin]

This fixes the issues described in #122. The main one being that currently filters are applied differently to getDescription() than to getFilteredChildren(). That means that the set of tests that getDescription() says will be run are not actually the set of tests that are actually run.

e.g. After applying the ShardFilter to your above example getDescription() might return:

testMethod
    testMethod_a
    testMethod_b
    testMethod_c

But getFilteredChildren() might return the following tests:

    testMethod_a
    testMethod_c

I will rebase, fix merge issues and upload a new fix soon.

[zbychupragmatists]

I'm afraid you don't get exactly our point. We tested your PR and in fact it changes how Description objects are return from getFilteredChildren() but still you cannot achieve a goal that you would like to filter few parameters from one parametrized method (e.g. to rerun only those which failed). Please look once again in example @woprzech provided - filtering one method for single parameter (e.g. parameter a in testMethod) is not possible in master and neither your PR.
But maybe problem is that you are trying to achieve something else and from description in #122 we are not sure what - please correct us if we are doing wrong assumptions.

[tbroberg]

This looks suspiciously like what I would do to fix #52 (which is definitely not fixed).

Specifically, it overrides describeChild() in JUnitParamsRunner such that the test cases get named correctly so filters apply correctly, allowing test cases to be rerun.

[paulduffin]

I am still a little confused as to what it is that you think this is trying to do. It is possible that there's a bug in my code which means that it is not doing what I expect it to either.

Do you have a test, that fails with my change that you expected to work? Something that I can paste into my local repository, run, debug etc.