I think the problem that you might be facing is more related to the quality of your tests than testing itself. If your tests are written correctly, you should never have to throw them away when you refactor.
In fact, that's one of the major benefits of testing: a refactoring safety net!
Right. How can you refactor code that has no tests? Basically, you've got no clue if your new refactored code works because all the precious time you've spent using the old code went towards ephemeral tests that weren't written down. That makes refactoring a lot more risky than it needs to be.
Comments
I think the problem that you might be facing is more related to the quality of your tests than testing itself. If your tests are written correctly, you should never have to throw them away when you refactor.
In fact, that's one of the major benefits of testing: a refactoring safety net!
Right. How can you refactor code that has no tests? Basically, you've got no clue if your new refactored code works because all the precious time you've spent using the old code went towards ephemeral tests that weren't written down. That makes refactoring a lot more risky than it needs to be.
What I meant to say is "How can you effectively refactor code that has no tests?"
Refactoring is inevitable. I find that on projects where I've written tests, refactoring goes a lot better.
By refactor he means to change the purpose of the code, not just the implementation. Your tests will not cover this.
Does he? Then he's using the wrong word. Refactoring is changing the implementation while keeping the interface and semantics.
Which, I agree, is one of the shortcomings of unit testing: placing an additional burden on improving interfaces and semantics.