In Test-Driven Development, I used to think it was a waste of time to write only enough code to make a test pass. I felt that if the code was not completely correct, why should I write it? Now, I feel differently.
Some of the examples you will encounter while learning about TDD may seem downright ridiculous to you…they did to me. These examples often promote the idea that I should write a test, then write the code to simply return the expected value so the test will pass. This seems pointless since it is obvious that the code is wrong, but the test passes. Why would I want to do that? For quite sometime I just didn’t get it, but now I do.
The reason you want to get the test to pass is to enable you to continue writing another test for the functionality that you just faked. And to do so without having other tests failing. The concept is called “Fake it ’till you make it”. Take for example the classic bowling game example. The first test is usually:
[Test]
public void A_game_of all_gutter_balls_should_have_a_score_of_zero()
{
BowlingGame game = new BowlingGame();
for ( int i = 0; i <= 10; i++ )
game.throw( 0 );
Assert.AreEqual( 0, game.Score );
}
If we followed the rule of only making the simplest thing possible that will work, we would write the BowlingGame as follows:
public class BowlingGame
{
public int Score
{
get { return 0; }
}
}
This is all that is needed to actually make the test pass and we can move on. Why is it ok to do this, knowing that return 0; is not the final correct implementation? Its ok because this is an intermediate step. You should soon remedy this situation by writing more tests.
In fact, having all your tests pass, but seeing that the implementation is not correct is a code smell that indicates you need more tests to fully specify the functionality you are missing. If you know the code is incomplete, yet all your unit tests pass, you know that the functionality that is missing from your code (that makes it incomplete) is missing tests to specify and validate its behavior.
Write a test to make the current implementation fail and specify the missing behavior so you can write the code to implement it. If you can’t conceive of a new failing unit test, then perhaps the current implementation is correct after all, or perhaps you are trying to over-design the code when a more simpler solution will suffice.
-=CE=-
