Up to this point, I have been developing tests for the support of a certain application in my project. Now that I have a set of tests up and running, I need to provide support for another similar application. The result for both applications should be the same in my system, as they both produce the same actions but from different contexts. The thing is, I am looking for a way with which I could reuse the tests that I have made for the first one, without copying their code for the other test case.
I am currently using JUnit 4 under Java EE 8.
My situation goes something like this. Given a test like the one that follows:
class TestExample {
Context context;
@Before
public void setUp() {
context = new ContextA();
}
@After
public void terminate() {
context.dispose();
}
@Test
public void test1() {
context....
}
}
abstract class Context {
@Override
public void dispose() {
...
}
}
class ContextA extends Context {
}
class ContextB extends Context {
}
I would like to be able to do the test once for ContextA and then for ContextB.
---o---
So after coming back at this problem after a while, I have gathered from this thread three possible solutions to my problem:
However, after trying them all out on real test cases I have found none of them to be perfect solutions. They do solve the problem that I have presented on this question, but the moment a real case comes in and the contexts start differing slightly between them then these options start becoming complex and ugly.
In the end, I have opted for the simplest solution: copying the tests source code for each different context. It works, but the problem with this is that maintaining the tests gets harder and harder with time as a change to a single test must be replicated to all the copies of it.
How do I reuse JUnit test methods for different testing contexts?
Typically, you do not.
One core point of unit tests is: they help you to quickly identify bugs when you made changes to your production code later on. Meaning: a primary requirement for unit tests is that you are able to read and understand them quickly. Anything that makes that harder, like "complex" solutions to avoid code duplication is problematic.
From that point of view, the "rules" for test code are sometimes not the same as for production code. In production code, you want to avoid code duplication at (almost) all cost.
Yet, for test code, it can be perfectly fine to have two different test classes that do very similar things ... two times. Maybe, just maybe you extract common code into helper methods (like doing a specific, complicated assert) into some utility classes.
Having said that, one potential solution: if you really want to run the exact same tests on multiple "inputs", then I suggest you look at parameterized tests for example. Instead of hard-coding your context instance within @Before code, you could simply have multiple different context objects, and run all tests for each of those.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With