3 ms·

Usually my unit tests are tightly coupled to the module they're testing, but the modules themselves are loosely coupled from the rest of the system. In most ca

Usually my unit tests are tightly coupled to the module they're testing, but the modules themselves are loosely coupled from the rest of the system. In most cases I want to preserve existing behaviour, so I don't want any existing tests to fail. I'll add tests for the new behaviour in the relevant modules, add code to make them pass, and then if necessary update the glue code / integration tests which cross the boundary. Pretty much by definition, a refactor of code should not change its behaviour. My tests usually assert on behaviour observed at the boundaries of modules, so they should still pass during refactorings.

dllthomas 11y ago
> Pretty much by definition, a refactor of code should not change its behaviour. Quite precisely by definition, perhaps for other reasons as well :-P > My tests usually assert on behaviour observed at the boundaries of modules, so they should still pass during refactorings. I find the kind of refactoring that most desperately needs the support of tests is changing the boundaries of the individual units. Unit tests can still arguably be useful there in making me clarify the changes I'm making to my interfaces... but they do need changing, and I can't be quite as confident that nothing is breaking if I'm changing both code and tests in tandem.