Incorporate classpath scanning suite into core JUnit? about junit4

[dsaff]

Georg,

I'd love to see something like this submitted to the junit.contrib project that I'm hoping to start up soon. Let me know if you're still interested, and thanks for your patience.

[dsaff]

Georg,

I never heard back from you. Are you still interested in working on this? Thanks.

[aisrael]

Just a question (for the sake of discussion): Would the proposed @SuiteMethod annotation in #41 work for you?

[georgthimm]

In principle, this works, but I would not consider this particularly convenient:
at least, a method needs to be implemented, which delegates to a static method somewhere (with the in-/exclude patters as arguments).
Furthermore, I find the syntax of my proposal much clearer.
I'd give, though, credit to you methods for more flexibility.
For me, the question angles around the answer to "how much flexibility is needed?".
IMHO - call me narrow minded if you wish ;-) - very little: the more complicated, the easier some tests "escape". The fine-tuning of tests, again - IMHO, should happen using the Assume-methods.

Do you have some software to test for which my proposal does not work?

[Yishai]

For me it would not be enough. Sometimes I need to be able to group tests by name and location (that is the name is different depending on which directory). Why, because some tests are done as static inner classes to production code, while others are done in a separate test directory, and the separate test directory has a wider range of classes to include.

Sometimes I just want to slurp up all classes with an @test annotation in them.

[georgthimm]

Dear Yishai,

To "slurp up" all classes based on whether they have a @test annotation in them is not possible (to add some reflective inspection of the code wouldn't be too difficult, but very slow).

HOWEVER, I believe that inner classes are handled correctly, but I will run some examples first. Also, separate directories are no problem, as long as they are included in the class path.

I'll post examples asap...

Regards,
Georg

[georgthimm]

Dear Yishai,

here comes the promised example-cum-test for my modified Suite class. Both, the suites and the test-classes are inner classes. If you have the in the earlier post included Suite in your class path, you can run this class as a test or run the inner Suites individually.

Does this meet your needs?

Georg

package org.jlinalg.testutil.junit;

import static org.junit.Assert.assertTrue;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

import org.jlinalg.testutil.junit.Suite.SuiteClasses;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.JUnitCore;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;

/**

• Tests for the execution of tests in inner classes.

• @author Georg Thimm
  /
  @RunWith(Parameterized.class)
  public class RunSuiteTest
  {
  /*

  • Tests add the class to which they belong here. This is used to assert
  • that tese tests were executed.
    */
    static List<Class> log = new ArrayList>();

  /**

  • 1st fixture: a suite based on a static class
    _/
    @RunWith(Suite.class)
    @SuiteClasses(include = "._RunSuiteTestFixtureClass.*")
    public static class StaticRunSuiteTestTest
    {
    }

  /**

  • 2st fixture: a suite based on a non-static class
    _/
    @RunWith(Suite.class)
    @SuiteClasses(include = "._RunSuiteTestFixtureClass.*")
    public class RunSuiteTestTest
    {
    }

  /**

  • Inner class with a test (used by both fixtures).
    */
    public static class RunSuiteTestFixtureClass_1
    {
    @test
    public void test()
    {
    log.add(getClass());
    }
    }

  /**

  • Inner class with a test (used by both fixtures).
    */
    public static class RunSuiteTestFixtureClass_2
    {
    @test
    public void test()
    {
    log.add(getClass());
    }
    }

  /**

  • @return A list arrays defining fixtures
    */
    @parameters
    public static List<Object[]> data()
    {
    Object[][] data_ = {
    {
    StaticRunSuiteTestTest.class
    }, {
    RunSuiteTestTest.class
    }
    };
    return Arrays.asList(data_);
    }

  /**

  • initialised fixture.
    */
    private final Class<?> testSuiteClass;

  /**

  • Constructor
    */
    public RunSuiteTest(Class<?> testSuiteClass)
    {
    this.testSuiteClass = testSuiteClass;
    }

  /**

  • Test the execution of test suites.
  • @throws ClassNotFoundException
    */
    @test
    public void testRunSuite() throws ClassNotFoundException
    {
    JUnitCore runner = new JUnitCore();
    runner.run(testSuiteClass);
    assertTrue("log=" + log, log.contains(RunSuiteTestFixtureClass_1.class));
    assertTrue("log=" + log, log.contains(RunSuiteTestFixtureClass_2.class));
    }

  /**

  • clean the {@link #log}.
    */
    @before
    public void before()
    {
    log.clear();
    }
    }

[Yishai]

georgthimm,

Thanks for the code. It may be slow to slurp up all the classes, but my point is that with a method that I can can control the programming of, I can do what I need (even if it is slow). With your solution, it is better than the current situation, it doesn't give the freedom to programatically take the classes from where I need them the way I need them. I have nothing against your suggestion, I'm just saying that it doesn't offer the same power as having a method that can return any array you can program.

[georgthimm]

Welcome! No offence taken, just me defending my stupid idea ;-)
I can see the advantages of your approach, and time isn't my main concern: robustness and easy to use are.
Cheers,
Georg