It means that either:
- You wrote the production code that fulfills the feature you want without writing the test first (a violation of "religious TDD"), or
- The feature that you need happens to be already fulfilled by the production code, and you're just writing another unit test to cover that feature.
The latter situation is more common than you might think. As a completely specious and trivial (but still illustrative) example, let's say that you wrote the following unit test (pseudocode, because I'm lazy):
public void TestAddMethod()
{
Assert.IsTrue(Add(2,3) == 5);
}
Because all you really need is the result of 2 and 3 added together.
Your implementing method would be:
public int add(int x, int y)
{
return x + y;
}
But let's say I now need to add 4 and 6 together:
public void TestAddMethod2()
{
Assert.IsTrue(Add(4,6) == 10);
}
I don't need to rewrite my method, because it already covers the second case.
Now let's say that I found out that my Add function really needs to return a number that has some ceiling, let's say 100. I can write a new method that tests this:
public void TestAddMethod3()
{
Assert.IsTrue(Add(100,100) == 100);
}
And this test will now fail. I must now rewrite my function
public int add(int x, int y)
{
var a = x + y;
return a > 100 ? 100 : a;
}
to make it pass.
Common sense dictates that if
public void TestAddMethod2()
{
Assert.IsTrue(Add(4,6) == 10);
}
passes, you don't deliberately make your method fail just so that you can have a failing test so that you can write new code to make that test pass.