4 ms·
Your complaints are actually the whole reason tests exist. Of course you know that your code works when you write it. You then write tests that are tightly coup
by woah 12y ago
Your complaints are actually the whole reason tests exist. Of course you know that your code works when you write it. You then write tests that are tightly coupled to the behavior that you require from the code to run it through its paces as you work on it.
Speaking of coupling, tests prevent tight coupling between different pieces of your codebase. Since there are then at least 2 consumers of any piece of code, the implementation does not get coupled to a particular one as easily.
Also, if you would like to work with a module or microservice based approach, tests are simply necessary to work. If you're storing different pieces of the codebase in different repos, you will need to have tests to work on them at all.
Basically, if you are "testing" your production code with other pieces of your production code (I hope you don't do this), it will become tightly coupled. Test your code with tests.
- Iftheshoefits 12y agoI'm not sure we disagree about the purpose and utility of tests. I certainly was not complaining about tests. If anything, I was complaining that too often, in my experience at least, it seems to be presented as an undeniable truism that, generically, 'tests' are always a benefit, and usually the more tests the better. My point is that tests (at least, unit/integration tests of the variety usually mentioned in TDD) are more code that has to be maintained (and designed, and debugged). They incur overhead and as such impinge on development resources. As a result tests introduce the need for considering tradeoffs between developing tests and developing the software product itself. Simply writing tests for the sake of having tests to test code is naive; at least as naive as assuming that once working a given piece of code works forever, but it is a mistake that I've witnessed on more than one occasion.