[LRUG] TDD when removing functionality

[Paul Robinson]

On 19 Sep 2012, at 10:45, Ian Kynnersley <iankynnersley at gmail.com> wrote:

> I understand the value of the tests showing me whether the changes are breaking things I don't want to break but I can't see how to actually test-drive the removal of the code. Does anyone have any good experience of using TDD for this? Or should I just delete the code, delete the tests, make sure the remaining tests don't fail and stop worrying about it?


I've seen people get into a tangle because they have (rightly) decided before they start a task of adding something functional to the product, there should be tests to ensure the functionality is correct, and that assumptions made when building previous functionality still holds.

The key word here is "adding", I think.

So with that in mind, perhaps step back and ask what the tests are there to do: I would argue, they capture the assumptions made about how the product must function.

So if you're removing functionality, the tests corresponding to that functionality should be removed.

You might want to check old behaviour is no longer present if an assumption from the PO is that the removed functionality is now absolutely impossible to achieve, but that's not quite the same thing as checking the functionality has been successfully removed. Instead, you're aiming for a validation of the assumptions that remain, and have now been added to, just done more rigorously.

Don't be afraid to remove tests that are breaking IF they are breaking because they are capturing assumptions about functionality you no longer want in the product. Only add new tests if assumptions are being added or changed. That's where I'd go.

Paul