This is an AMP version of the article, its original content can be found here.
Test Methods Must Share Nothing
Constants... I wrote about them some time ago, mostly saying that they are a bad thing, if being public. They reduce duplication, but introduce coupling. A much better way to get rid of duplication is by creating new classes or methods—a traditional OOP method. This seems to make sense and in our projects I see less and less public constants. In some projects we don't have them at all. But one thing still bothers me: unit tests. Most programmers seem to think that when static analysis says that there are too many similar literals in the same file, the best way to get rid of them is via a private static literal. This is just wrong.
Unit tests, naturally, duplicate a lot of code. Test methods contain
similar or almost identical functionality and this is almost inevitable. Well,
we can use more of that
but sometimes it's just not possible. We may have, say, 20 test methods
FooTest.java file. Preparing all objects in one "before" is not
possible. So we have to do certain things again and again in our test
Let's take a look at one of the classes in our Takes Framework:
It's a unit test and it has a problem, which I'm trying to tell you about.
Look at that
private literal. It is used for the first time in
as an argument of an object constructor and then in a few
test methods to check how that object behaves. Let me simplify that
This is basically what is happening in
and it's very wrong. Why? Because this shared literal
introduced an unnatural coupling between these two test methods.
They have nothing in common, because they test different behaviors
Foo. But this private constant ties them together. Now they are
If and when I want to modify one of the test methods, I may need
to modify the other one too. Say I want to see how
behaves if the encapsulated message is an empty string. What do I do?
I change the value of the constant
FooTest.MSG, which is used by
another test method. This is called coupling. And it's a bad thing.
What do we do? Well, we can use that
"something" string literal in
both test methods:
As you see, I got rid of that
setUp() method and the private static
MSG. What do we have now? Code duplication. String
shows up four times in the test class. No static analyzers will tolerate that.
Moreover, there are seven (!) test methods in
which are using
MSG. Thus, we will have 14 occurrences of
Yes, that's right and that's most likely why one of authors of this
test case introduced the constant—to get rid of duplication.
BTW, @Happy-Neko did that in pull request
@carlosmiranda reviewed the code and I
approved the changes. So, three people made/approved that mistake, including myself.
So what is the right approach that will avoid code duplication and at the same time won't introduce coupling? Here it is:
These literals must be different. This is what any static analyzer is
saying when it sees
"something" in so many places. It questions us—why are they the same? Is it really so important to use
Why can't you use different literals? Of course we can. And we should.
The bottom line is that each test method must have its own set of data and objects. They must not be shared between test methods ever. Test methods must always be independent, having nothing in common.
Having that in mind, we can easily conclude that methods like
any shared variables in test classes are evil. They must not be used
and simply must not exist. I think that their invention in JUnit caused
a lot of harm to Java code.