Can someone explain "Fake it till you make it" approach in Test Driven Development?

Question

I have a problem to understand the evolution of code when you have taken the "Fake It Until You Make IT" TDD approach.

Ok, you have faked it, let's say you returned a constant so that the broken test is green in the beginning. Then you re-factored your code. Then you run the same test which is going to pass obviously because you have faked it!

But if a test is passing how can you rely on that, especially when you know that you faked that?

How should the faked test be refactored with your real code refactoring so that it can still be reliable?

Thanks

Answer 1

The short answer is: write more tests.

If the method is returning a constant (when it should be calculating something), simply add a test for a condition with a different result. So, let's say you had the following:

@Test
public void testLength()
{
    final int result = objectUnderTest.myLength("hello");
    assertEquals(5, result);
}

and myLength was implemented as return 5, then you write a similar (additional) test but pass in "foobar" instead and assert that the output is 6.

When you're writing tests, you should try to be very vindictive against the implementation and try to write something that exposes its shortcomings. When you're writing code, I think you're meant to be very laissez-faire and do as little is required to make those nasty tests green.