Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

My question is whether I should test code that I know will be changed in a short time. I'm doing TDD in ruby, and I often meet with this question. I'm interested about best practices about this, pro and contra. Thanks.

Update

Clarification: My question is basically how do you compare the 'cost of writing a test' VS 'the fact that the code will change soon' and make decision.

share|improve this question
add comment

7 Answers

up vote 4 down vote accepted

Yes.

That way you know that your change hasn't broken the code.

You should be testing to the interface/API so you can change the underlying methods without having to rewrite the tests. Then, when the tests turn green again you know you've sucessfully refactored/rewritten the code.

New tests can be added to test new functionality.

share|improve this answer
    
Perhaps he is saying that he knows the interfaces will change? –  user1249 Jan 30 '11 at 11:33
    
@Thorbjørn - that's a point. In which case my answer is useless ;) –  ChrisF Jan 30 '11 at 11:35
add comment

If the code will be in used, it should be tested.

share|improve this answer
add comment

Yes, and most importantly make tests that will still run after the changes without the test code needing to change. To achieve this you could put the code likely to change behind an interface or wrap it with something that delegates to it if you think its or class structure will change.

This answer assumes that you currently have code-A that provides a feature. It will be replaced with code-B which is quite different but also provides the same feature. If so, you need tests that test that this feature works and you'll need to make the effort to design/refactor code-A correctly so that it can be changed to code-B without the tests changing.

share|improve this answer
add comment

Surely if you're doing TDD this isn't even a question?

You write tests for the code before you write the code - that's it. Done (-:

If the code you want to change doesn't already have tests then yes, things are suddenly a bit more interesting - ideally however you want to add tests to the code that isn't currently covered so that when its changed you are able to have confidence that what you're doing isn't breaking stuff.

Finally there's the assertion that "the code will change soon" - how confident are you that that will actually happen? That's a serious question... I've had code I wanted to change/fix for the best part of 5 years - bad as it was (and some of it was and other bits were just ) it worked to varying degrees of adequacy and the opportunity to change it never arose. (I suspect having tests would have help create the opportunity.)

share|improve this answer
    
Yes, you are right about the tdd :) Lets say that I'm 100% confident that the code will change because the specs are not clear, and I know and the code has dependencies on other part of the application that are not yet implemented. –  dombesz Jan 30 '11 at 18:02
    
Ah... that's interesting... the code may change but will the function of the code - which ultimately is what you're testing. –  Murph Jan 31 '11 at 10:32
add comment

How much will the code change?

If you only expect the code to be modified a bit, then it would make sense to write the tests for the code you have an modify at the same time you modify your code. If your code is basically going to be thrown a way, it probably isn't worth your time writing tests for it. This can be tricky because throw away code tends find itself in production.

This really is a judgement call on your part, as there really isn't a checklist to work from. My guess is that you or someone else wrote the code for a reason, and if there's any potential that it will not be completely rewritten or trashed, write the tests. It's good practice.

share|improve this answer
add comment

This is very subjective. If you are talking about swapping out implementations, then I agree, it makes sense to test against the interface. If you are modifying the interface you are programming against, then I personally would just keep a todo/comment to remind myself to come back to it and test it later.

share|improve this answer
add comment

I would still say yes, you should write the tests. If it's just the internal algorithms / logic / structure that will change, then your tests may still be after the change. Even if the change will be more substantial than that, having the tests will remind you of what your assumptions were in the previous design, and will give you hints on the things you need to test in the new design. You may still have to write new tests (and maybe remove some of the old ones) after the change, but it will be a valuable to process to think through.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.