I\'ve heard that projects developed using TDD are easier to refactor because the practice yields a comprehensive set of unit tests, which will (hopefully) fail if any change has
Kent Beck's TDD book.
Test first. Following S.O.L.I.D OOP principles and a using a good refactoring tool are indispensable, if not required.
Under what situations in TDD is it okay to alter and delete test cases? How can you be sure that altering the test cases don't break them? Plus it seems that having to synchronize a comprehensive test suite with constantly changing code would be a pain.
The point of tests and specs is to define the correct behaviour of a system. So, very simply:
if definition of correctness changes
change tests/specs
end
if definition of correctness does not change
# no need to change tests/specs
# though you still can for other reasons if you want/need
end
So, if application/system specifications or desired behaviour changes, it is a necessity to change the tests. Changing only the code, but not the tests, in such a situation is obviously broken methodology. You might look at it as "a pain" but having no test suite is more painful. :) As others have mentioned, having that freedom to "dare" to change code is very empowering and liberating indeed. :)