Hacker News Reader

Can someone address the argument of:

Writing tests for everything (or almost everything) as proposed by TDD results in... more code to maintain.

This is the argument most teams have had that I’ve observed which resulted in little to no tests added.

I’ve seen above in both small teams (startups), and large orgs,

Yes, more automated tests (TDD or not) do imply more code. The question is whether building and maintaining that code is cheaper than the fallout from the bugs that get through to the customer. And the answer to that is, after the team or product grows past a certain size, that equation always tilts in favor of having the tests.

It only makes sense to write tests for behavior you don’t expect to change often. There is no point in writing a test for something that is incomplete or will obviously need to be changed.

Reply on news.ycombinator.com