Question

I’m trying to get my head around TDD methodology and have run into – what I think is – a chicken-and-egg problem: what to do if a bug fix involves the changing of a method’s signature.

Consider the following method signature:

string RemoveTokenFromString (string delimited, string token) 

As the name suggests, this method removes all instances of a token from delimited and returns the resultant string.

I find later that this method has a bug (e.g. the wrong bits are being removed from the string). So I write a test case describing the scenario where the bug occurs and make sure that the test fails.

When fixing the bug, I find that the method needs more information to be able to do its job properly – and this bit of information can only be sent in as a parameter (the method under test is part of a static class).

What do I do then? If I fix the bug, this compels me to change the unit test – would that be ‘correct’ TDD methodology?

Answer 1

There is absolutely nothing wrong with bombing your tests, when you discover that the intended behaviour of the unit changes.

//Up front [Test] public void should_remove_correct_token_from_string() {   var text = 'do.it.correctly..';   var expected = 'doitcorrectly';   Assert.AreEqual(StaticClass.RemoveTokenFromString(text, '.'), expected); }  //After finding that it doesn't do the right thing //Delete the old test and *design* a new function that //Does what you want through a new test //Remember TDD is about design, not testing! [Test] public void should_remove_correct_token_from_string() {   var text = 'do.it.correctly..';   var expected = 'doitcorrectly';   Assert.AreEqual(       StaticClass.RemoveTokenFromString(           text,           '.',           System.Text.Encoding.UTF8), expected); }  //This will force you to add a new parameter to your function //Obviously now, there are edge cases to deal with your new parameter etc. //So more test are required to further design your new function