Unchained Test Fixture Override
ID |
java.junit3_super_setup |
Severity |
critical |
Remediation Complexity |
trivial |
Remediation Risk |
low |
Remediation Effort |
low |
Resource |
Reliability |
Language |
Java |
Tags |
best-practice, junit, testing |
Description
Reports a setUp or tearDown method in a junit.framework.TestCase hierarchy that overrides an implementation inherited from an intermediate base class without calling super.setUp() / super.tearDown().
Rationale
An intermediate test base class exists precisely to hold fixture logic shared by its subclasses — a connection, a temporary directory, a clock. Overriding its hook without chaining drops all of that for one subclass, and for that subclass only.
Nothing signals the problem. The base class keeps working for its other subclasses, the overriding class still compiles, and its tests still run — against a fixture that is only half built. The shared logic also tends to grow over the life of a codebase, so a subclass that was harmless to write this way silently falls further behind every time the base gains a line.
abstract class AbstractInvoiceCase extends TestCase {
protected StubClock clock;
public void setUp() {
clock = new StubClock();
}
}
public class InvoiceTotalsTest extends AbstractInvoiceCase {
public void setUp() { // clock is never created for this test
totals = new InvoiceTotals();
}
}Remediation
Call the inherited hook first in setUp, and last in tearDown, so the fixture is built outwards and torn down inwards.
public class InvoiceTotalsTest extends AbstractInvoiceCase {
public void setUp() {
super.setUp();
totals = new InvoiceTotals();
}
public void tearDown() {
totals = null;
super.tearDown();
}
}What is not reported
A class extending TestCase directly is left alone: the inherited hook is the framework’s own empty one, so there is nothing worth chaining to. A hierarchy whose base class is declared in another file is also left alone — the rule cannot see whether that base declares the hook, and stays quiet rather than guess.