Hacker News Reader

Comment by okl | Hacker News Reader

Assuming that the amount of test code is 2-4x the amount of production code, TDD increases the cost of change by 2-4x when change is most likely to occur: at the beginning of development.

View on HN

Likelihood of change and cost of change are different. A codebase which is very large is, all other facts held equal, much harder to change. While a small, early codebase may iterate very rapidly, drag will increase. The question is whether in the expected lifetime the higher upfront cost of providing tests pays off in average velocity.

Agreed, it increases linearly. But now think about the cost of change without tests. The longer you wait to introduce the change the more you will have to change (increases exponentially). If this code was fully tested and maybe refactored (isolated) when the need arises, the cost of change would almost go to 0 because you would only have to implement a new feature without touching the old code.

You assume that changing a software that has tests is free, which is wrong.

Your previous-to-last sentence applies equally to a software project with or without tests.

> If this code was fully tested and maybe refactored (isolated) when the need arises, the cost of change would almost go to 0 because you would only have to implement a new feature without touching the old code.

You don't even know the "change", you just assume that it will be a change that takes zero effort to implement, to satisfy your argument.

I don't really get what testing has to do with whether or not a piece of code is isolated or not? For example if you're making a change to a 4 line function with a clearly defined interface, the change is probably going to be trivial, regardless of whether the interface is defined by a set of unit tests or a short comment above the function declaration

Reply on news.ycombinator.com