RunWith(Enclosed.class) should run tests in outer class

[christophsturm]

in this example:

@RunWith(Enclosed.class)
public class OuterClassTest  {
    @Before
    public void startStore() throws Exception {
...
    }

    @Test
    public void outerTest1() {
...
    }

    public static class PoolTest extends JedisPoolTestBase {
        private StatisticsStore storer;

        @Before
        public void setupStorer() {
        }


         @Test
         public void innerTest1() {
          ...  
         }
    }
}

only innerTest1 runs.
It would be more useful if outerTest1 was also run.
also @before classes in the outer class should run for tests in the inner class.
thats how nested tests work in other languages.
is this easily possible?

[dsaff]

It's possible, but complicates the meaning of the runner for what feels like little benefit.

[brandonheck]

I agree that running tests in the enclosing class is a bit out-of-scope for the intention of the enclosed runner, but I do feel that the enclosed runner should be enhanced to run other fixtures from the enclosing class. For example, I have a set of test classes that all rely on applications deployed to a remote system. I use a @BeforeClass in the enclosing class to deploy the applications, and a @afterclass to undeploy the applications, but I would like for these fixtures to be run only once for the duration of the enclosed test classes.

[dsaff]

@brandonheck, that should already work. Have you tried?

[brandonheck]

I'm not sure what I am doing wrong in my actual tests, but I distilled my case into a simple case and it seems to work for everything except @before and @after, though based on the comment to the OP I would guess that it is not intended to work with the @before and @after fixtures.

Just in case it is, here's a test case for those (Junit 4.11, ran with the Eclipse Junit Runner and Maven/Surefire):

@RunWith(Enclosed.class)
public final class EnclosedTest {
public static String sharedStringBefore;
public static String sharedStringAfter;

@Before
public void before() {
    sharedStringBefore = "abcdef";
}

@After
public void after() {
    sharedStringAfter = "ghijk";
}

public static class EnclosedClass1 {
    @Test
    public void testEnclosed() {
        assertNotNull("The string is null.", sharedStringBefore);
    }
}

public static class EnclosedClass2 {
    @Test
    public void testEnclosed() {
        assertNotNull("The string is null.", sharedStringAfter);
    }
}

}

[dsaff]

Sorry to be confusing. Did you try it with @BeforeClass and @afterclass?

[brandonheck]

Yeah, sorry I'm also kind of jumping around. @BeforeClass and @afterclass work, but it would be nice to have @before and @after work as well.

[dsaff]

@brandonheck, what would you expect @Before and @After to do?

[brandonheck]

I would expect a @before or @after method in the enclosing class to function as if it were in every enclosed class, the would be run before/after each test in all of the enclosed classes.

[dsaff]

@brandonheck,

In general, I hope that developers can use Rules to share before/after behavior between multiple classes, whether they're bound together by Enclosed, or not.

[VishvendraRana]

@brandonheck did you get to run testcases that are defined in enclosing class ( in @christophsturm's example outerTest1)? Actually I am also searching for the same but didn't find any help. If something worked for you then can you tell me what you did?

[marcphilipp]

Have you tried using HierarchicalContextRunner by @bechte?

[VishvendraRana]

Thanks @marcphilipp. It works good. But as this is a third party runner. So we have to add patch for this. Is there not any other solution?

[Citizen-T]

@VishvendraRana
There is a hack that works. Basically you need to make your "outer" @before and @after part of a inner class with a dummy test. Then your other contexts need to extends that class. The only place I've seen this explained is in Uncle Bob's clean coders episode #20 (https://cleancoders.com/episode/clean-code-episode-20/view). Pay the couple of bucks and check out the video at about 1:02.

I had a lot of hope for HierarchicalContextRunner, but in my limited testing I found that it didn't play well with categories.

[bechte]

@Citizen-T: If you experience issues with the use of Categories and the HierarchicalContextRunner, please file an issue on GitHub and I will fix it. It really should not be an unsolvable issue. Please provide some more information so I can solve the limitations. Thanks. :-)

@VishvendraRana: The HierarchicalContextRunner serves your needs. You can simply add the runners jar to your test-classpath. In order to add tests, you also modify code, so there should be a need for a patch either way, shouldn't it? There are no limitations in use of this library, just like JUnit itself.