Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The problem with this is that the tests become obstacles in the way of refactoring the code.

I'm not a TDD stickler or anything, but tests are what make refactors even possible. Will tests catch all the issues? No, but they will make sure the part you refactored still interacts properly through its public interface.

If some tests have to be changed that is even better because those tests hopefully contain corner cases that have been caught and tested for over the life of the original code, and will force the person doing the refactor to think about those issues.



I'm not a TDD stickler or anything, but tests are what make refactors even possible.

Perhaps in general tests provide a useful safety net for refactoring, but I think the benefits are often overstated. In any case those tests don't have to be unit tests.

If I'm working on the kind of system that would need mocks for comprehensive unit testing, I'd rather either use integration or high level functional tests if that kind of strategy is viable. At least then I'm still testing that my actual production code works.

If that's not possible, for example because I'm integrating with an external system where I can't test operations that would cause real side effects, I'd rather look for a different strategy entirely. For example, I might change the design to better isolate the bits of code I can control and test myself, I might (re)implement riskier areas in languages with powerful systems that will guarantee various classes of programmer error can't happen, or I might not have an automated test suite covering some code at all and rely on things like code review or automated code analysis tools instead.


If you need to modify the tests together in a parallel fashion to the modifications you make in the code you are more likely to introduce same conceptual bugs in both places.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: