Hacker News Reader

Comment by Iftheshoefits | Hacker News Reader

Here is another one: failing to understand that tests introduce additional maintenance and design overhead.

Quis custodiet ipsos custodes?

Tests are additional code that is tightly coupled to the target code that is meant to be used in production. This additional code requires design, debugging, and maintenance just like the target code. It is also tightly coupled to the target codebase: a change in either necessitates at least an inspection to determine what, if any, changes must then be made in the other.

This all adds overhead to the whole process, and too often I see casual, glib statements implying or even asserting that the overhead is nonexistent or else pays for itself. It isn't free and it is especially not free the more dogmatic the test proponents and tests themselves are.

View on HN

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.

I'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.

Testing obviously takes time. The problem with not having tests is that it takes time, but you don't necessarily know that it's taking time or how much. Lots of people think they are too smart to need tests, and it's just a waste of their time. But they are spending huge amounts of time fighting bugs, and even more bugs are getting out to users.

Agreed. I think Jay touches on this when talking about how you don't need to aim for 100% unit test coverage.

It's also what I mean by testing algorithmic code (where the pay off from the effort is large), versus testing coordinator code, where you are better off not unit testing it (because it is not complicated).

What's coordinator code like?

Code that glues together and orchestrate interactions between other code units etc. It's hard to test because of all the dependencies, but the actions it performs are not very complicated, so not worth the effort of unit testing.

For more, see: http://blog.stevensanderson.com/2009/11/04/selective-unit-te...

Reply on news.ycombinator.com