I think a pragmatic approach is the way to go here. This is what I think I'd do based on the scenario you desvribe:<br><br>1. Delete the code. <br><br>2. Delete or modify failing tests (some might be valid tests,  but failing anyway). <br><br>3. Read remaining tests around the area affected to see if they still make sense and I'm happy with coverage. <br><br>If there's a lot to delete I'd go through this loop a few times rather than once,  to keep things manageable. I'd also try to make small commits, rather than one big one. <br><br>Ian Kynnersley <iankynnersley@gmail.com> wrote:<br><br>This is something I regularly come up against and am never sure how best to go about it.<div><br></div><div>I have RSpec coverage for an app I'm making some changes to. The changes I'm making are to remove a section of the app.</div>
<div><br></div><div>I can identify which behaviour I'm removing by going through my tests but I can't figure out how to test the removal of the functionality. I guess I could add a load more tests in to test that the app no longer does something but this seems to be complicating the act of removing stuff.</div>
<div><br></div><div>Do I remove the code and ensure that the tests I'm expecting to break do indeed break? This doesn't seem like it would be that useful.</div><div><br></div><div>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?</div>
<div><br></div><div>Thanks!</div><div><br></div><div>Ian</div><div><div><br></div>-- <br>







<br>Ian Kynnersley<br><a href="http://iankynnersley.co.uk" target="_blank">http://iankynnersley.co.uk</a> | <a href="http://twitter.com/kpopper" target="_blank">http://twitter.com/kpopper</a><br>
</div>