Why write a custom runner/suite?
Usually Junit's default suite/runner combined with parameterized.class are great for parameterizing your tests. But the need to provide a specifically written constructor, and the need to add a specifically annotated and written method to your test class is rather annoying. The Collection syntax is also weird, though generic. To hide the details of parameterization, and provide such support simply through the use of @RunWith is what I am after. It is okay if my class has to implement another interface, but I would look to minimize impact on the user test class and coupling between test class and test infrastructure.
It is good that JUnit 4 has made it easier to write your own custom Suites and Runners.
How do suites and runners work?
In brief, a Junit Suite wraps around your test class and create a test 'runner' for your class.
A Suite can contain one or more test classes, but for design ease, I will always assume one suite contains one class.
This is how the Parameterized.class works too, the idea being that it creates as many runners for your test class as you specify in a specifically annotated method. Although quite generic, I would like to often create a runner that does not need the arcane syntax (a method with a Collection return type) as required by Parameterized.class.
In other words, I need to create my own parameterization, the details being hidden from the class using my custom suite.
Here is how I began work to achieve this (this post only covers part of the problem, I still have the need to provide a custom constructor, which I will eliminate in the future):
Step 1: Subclass Junit4 to create a custom runner, MyRunner
Step 2: Subclass Suite (create MySuite) to create as many instances of MyRunner (add each instance to a 'runners' list required by Suite)
So, MySuite extends Suite
MyRunner extends Runner
In MySuite constructor, add a method call to your additional method that creates a list of runners with your business logic.
That's it, with this, I then annotated my test class with @RunWith(MySuite.class), and had as many MyRunner per test class as I wanted. How many to create? this depends on what you want your suite to do. For example, you may have logic in your suite to create a runner per file type, thus achieving multi-file tests (of course, you wouldn't use this method for such a simple case)
What I don't like about this design
I use too much inheritance. If Suite or Junit4 classes change, my classes have to change too. My next step is too refactor and eliminate inheritance, replacing with interfaces to facilitate better dynamic dependency injection.
Hope you find this helpful. I will post a concrete example when I get a chance, and a followup post once I refactor it. hopefully Junit folks have already thought about this, or are working on it!
Usually Junit's default suite/runner combined with parameterized.class are great for parameterizing your tests. But the need to provide a specifically written constructor, and the need to add a specifically annotated and written method to your test class is rather annoying. The Collection
It is good that JUnit 4 has made it easier to write your own custom Suites and Runners.
How do suites and runners work?
In brief, a Junit Suite wraps around your test class and create a test 'runner' for your class.
A Suite can contain one or more test classes, but for design ease, I will always assume one suite contains one class.
This is how the Parameterized.class works too, the idea being that it creates as many runners for your test class as you specify in a specifically annotated method. Although quite generic, I would like to often create a runner that does not need the arcane syntax (a method with a Collection
In other words, I need to create my own parameterization, the details being hidden from the class using my custom suite.
Here is how I began work to achieve this (this post only covers part of the problem, I still have the need to provide a custom constructor, which I will eliminate in the future):
Step 1: Subclass Junit4 to create a custom runner, MyRunner
Step 2: Subclass Suite (create MySuite) to create as many instances of MyRunner (add each instance to a 'runners' list required by Suite)
So, MySuite extends Suite
MyRunner extends Runner
In MySuite constructor, add a method call to your additional method that creates a list of runners with your business logic.
That's it, with this, I then annotated my test class with @RunWith(MySuite.class), and had as many MyRunner per test class as I wanted. How many to create? this depends on what you want your suite to do. For example, you may have logic in your suite to create a runner per file type, thus achieving multi-file tests (of course, you wouldn't use this method for such a simple case)
What I don't like about this design
I use too much inheritance. If Suite or Junit4 classes change, my classes have to change too. My next step is too refactor and eliminate inheritance, replacing with interfaces to facilitate better dynamic dependency injection.
Hope you find this helpful. I will post a concrete example when I get a chance, and a followup post once I refactor it. hopefully Junit folks have already thought about this, or are working on it!
Comments
Post a Comment