2

I need the following test

@runwith(cache, memory) class CollectionA is -- this is a suite (aka folder) class Cache { -- this is a sub-suite (aka folder) @test testCache1() -- this is a method (aka file) @test testCache2() @test testCache3() } class RAM { -- this is a sub-suite (aka folder) @test testRAM1() @test testRAM2() } @test testIO() @test testKeyboard() @test testMouse() @test testMonitor() @test testPower() @test testBoot()

Please note that only Cache and RAM need to be grouped. The hierarchy helps to fight the complexity and run related tests, e.g. Cache subsystem, alone, when necessary. The problem that is as soon I use @runwith to do that grouping, all the single test methods besides the RAM and Cache collections are ignored by JUnit. It seems that you cannot have sibling files and folders in JUnit design. The comments in the official example of grouping also hints that

@RunWith(Suite.class) @Suite.SuiteClasses({ TestA.class, TestA.class }) public class FeatureTestSuite { // the class remains empty, // used only as a holder for the above annotations // HEY!!! WHAT ABOUT MY @Tests HERE? }

The answers say that whether I need to wrap every single test, e.g. testPower into their singletone suit or flatten the suite - get rid if the hierarchy completely.

So, is it right that JUnit is designed to disallow mixing single files (@test methods) with the folders (@runwith suites)? Why? How can this be worked around? Might be there is an alternative to @runwith.Suite?

Improve this question
6
  • I don't see what you are talking about WRT files and folders. You cannot have tests in a Suite. So but the tests in a Test class and include the Test in the Suite. There are no restrictions on what folder the tests reside in order for them to be included in the suite so long as the tests are public. You can add tests that are in the same folder (package) as the suite as well as tests that are in a different folder (package). Commented Sep 19, 2013 at 12:52
  • I see that you say that I cannot have tests in a suite. Can you make that an answer and may be explain the design so that I do not loose time at this pitfall. Commented Sep 19, 2013 at 13:18
  • The issue is that all the classes should be their own files. Don't use sub / inner classes. Commented Sep 19, 2013 at 13:23
  • I do not understand. If you tell that it is impossible to have tests in a Suite while suite class can be found anywhere then why nesting makes any problems? It is good thing, IMO, to nest syntactically things that are logically nested. Commented Sep 19, 2013 at 13:28
  • To use inner classes you would use the Enclosed runner, not the Suite runner. Using a Suite of separate classes allows you to 1: have smaller files 2: run an individual test Commented Sep 19, 2013 at 13:34

2 Answers 2

Reset to default
4

What you like to create is a mixin type, which is not supported by the JUnit runner. So yes, you are right, it is not possible out of the box.

For this purpose I created an add-on that can be used to create hierarchical contexts for your test. In my point of view this is a missing feature in JUnit and I also stay in contact to get this included into the JUnit core.

The add-on provides an HierarchicalContextRunner which allows to use inner class to group your tests into contexts. Each context can contain tests or other contexts. It also allows to have @Before, @After, @Rule methods and fields, as well as other feature like @Ignore of the standard Runner. :-)

Example:

@RunWith(HierarchicalContextRunner.class) public class CollectionA { public class Cache { @Test testCache1() {...} @Test testCache2() {...} @Test testCache3() {...} } public class RAM { @Test testRAM1() {...} @Test testRAM2() {...} } @Test testIO() {...} @Test testKeyboard() {...} @Test Mouse() {...} @Test testMonitor() {...} @Test testPower() {...} @Test testBoot() {...} }

Give it a try: https://github.com/bechte/junit-hierarchicalcontextrunner/wiki

Votes and feedback are highly appreciated. :)

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

That is it. But, I see that there are still some problems with using it, github.com/junit-team/junit/issues/732#issuecomment-24804304
1

Your design should be something like this:

// folder com.myco.project SuiteX.java TestA.java TestB.java // contents of TestA.java public class TestA{ @Test public void someTestInA(){...} } // contents of TestB.java public class TestB{ @Test public void someTestInB(){...} } // contents of SuiteX.java @RunWith(Suite.class) @Suite.SuiteClasses({ TestA.class, TestB.class }) public class FeatureTestSuite { // the class remains empty, // used only as a holder for the above annotations }

As I state in my comment, use separate java files for each test class. Do not use inner classes.

Improve this answer

5 Comments

How unnesting the subcollections enables the unit tests in the FeatureTestSuite? I see none in your example.
The Suite runner causes the tests in TestA and TestB to be executed when FeatureTestSuite is run. That is the point of the Suite runner.
Do you understand that TestA and TestB are executed (but @test methods inside FeatureTestSuite are not) so that executing methods is an issue while executing TestA and TestB is not?
As I believe I have stated, there should NOT BE ANY TESTS in FeatureTestSuite. A Suite does not contain tests, it links other test classes. Quit trying to make it do something it is not designed to do.
I believe I asked to make this the answer. You answered something different. Secondly, you may explain why it was designed this way and propose anything besides the Suite that allows mixing test collections with methods. In most of the cases, I will have only one test per (sub)suite. It is stupid to create a class and method for every test when single method suffices.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.