Unit Testing Anti-Pattern: Code Matching

Sometimes, tests imitate code, and not in a good way.

Here’s our tested code:

public String encode(String word) {
	String result = word + word.length();
	return result;
}

And here’s our test:

@Test 
public void howItsDone() {
	Encoder enc = new Encoder();
	String input = "hello";
	String result = enc.encode(input);
	
	assertEquals(input+input.length(), result);
	
}

Hard not to notice the similarity, right?

I’ve seen this anti-pattern many times, and it usually comes down to laziness. It may not seem such a problem, but it is.

First of all, we’re not testing anything here. If we’re checking anything at all, it is whether the compiler or the processor works correctly. This is not our job. Usually.

It does go deeper, though.

If the topic wasn’t test design, we’d talk about separating interface from implementation. Similarly, in tests we check the effect of the operation, regardless of its the implementation. One of the advantages we get from the separation, is that we can refactor code, without breaking the test, which means in the eyes of the observer, behavior has not changed.

However, the way our example test is written doesn’t imply just behavior, it implies intent of implementation. When we read the test, we already know what to expect in terms of result, and how the operation is performed.

As with most problematic tests, the problem is not about when we write the tests, and they pass. Let’s jump ahead, say six months.

Somebody changes the implementation and breaks the test. Now they needs resolve the problem, based on how “it’s supposed to work”. After all, the intent was already documented in the test by the original writer. What was she thinking? Are we in the right? Is there something we’re missing?

Tests are already a snapshot of behavior, locking code down. Let’s try to limit the lock down effect as much as we can.