4 ms·

TDD does work quite well if you follow it. Why do you think it doesn’t work in practice?

by auspex 6y ago

faeyanpiraat 6y ago
I’m not OP and do not want to state whether TDD works or not, but in my experience it would increase development work significantly on apps which have complicated state machines as their business logic. It would probably end up being less work overall, when we factor in all the bug fixing work, that would happen after such an app would’ve been released without TDD.
jniedrauer 6y ago
There may be a domain where it makes a lot of sense, but I've rarely encountered it. Writing and maintaining test code takes just as much time as any other code. You often encounter problems during the actual implementation part that challenge your preconceptions. So if you write the tests first, then you'll end up rewriting them many times. TDD also encourages you to write junk tests that provide no safety, which will then need to be maintained and fixed at every refactor. But the biggest problem is that others on the teams simply won't do it, and neither will you when a deadline looms near. TDD aspirations don't last very long in production. The one place where I think it works well is implementing a well defined protocol. If you have exact definitions for inputs and outputs, then writing the tests first can make things a lot easier. But it's rare when you have such a clean problem to solve.
jandrewrogers 6y ago
TDD makes the assumption that logic is modular and that correctness can be evaluated on small subsets of code in isolation. This is not actually true in some important software domains if you are designing the code correctly. For some software, behavioral correctness can only be evaluated in the context of runtime side effects from other parts of the system. Correctness is a property of the aggregate system, not its components. In these cases, most of the testing is high-level integration testing and writing proper tests is often sufficiently sensitive to implementation detail that you write them when the code is mostly complete so that they match the implementation detail. As an example, any data infrastructure software that uses non-trivial adapative scheduling to optimize concurrency and throughput famously has this property. It is also the primary reason things like database engines are effectively untestable until the code is nearly complete. In principle you could architect any software to be amenable to TDD, but for these cases the performance penalty implied by that architecture is so severe (literally on the order of 10x) that no one serious would design their software that way. In these cases, the same binary can pass testing on one machine and fail on another. It is a different discipline than classic TDD, and more critical as more software systems are implicitly distributed.

TDD does work quite well if you follow it. Why do you think it doesn’t work in practice?

by auspex 6y ago

TDD does work quite well if you follow it. Why do you think it doesn’t work in practice?

I’m not OP and do not want to state whether TDD works or not, but in my experience it would increase development work significantly on apps which have complicated state machines as their business logic. It would probably end up being less work overall, when we factor in all the bug fixing work, that would happen after such an app would’ve been released without TDD.

jniedrauer 6y ago

There may be a domain where it makes a lot of sense, but I've rarely encountered it. Writing and maintaining test code takes just as much time as any other code. You often encounter problems during the actual implementation part that challenge your preconceptions. So if you write the tests first, then you'll end up rewriting them many times. TDD also encourages you to write junk tests that provide no safety, which will then need to be maintained and fixed at every refactor. But the biggest problem is that others on the teams simply won't do it, and neither will you when a deadline looms near. TDD aspirations don't last very long in production. The one place where I think it works well is implementing a well defined protocol. If you have exact definitions for inputs and outputs, then writing the tests first can make things a lot easier. But it's rare when you have such a clean problem to solve.

jandrewrogers 6y ago

TDD makes the assumption that logic is modular and that correctness can be evaluated on small subsets of code in isolation. This is not actually true in some important software domains if you are designing the code correctly. For some software, behavioral correctness can only be evaluated in the context of runtime side effects from other parts of the system. Correctness is a property of the aggregate system, not its components. In these cases, most of the testing is high-level integration testing and writing proper tests is often sufficiently sensitive to implementation detail that you write them when the code is mostly complete so that they match the implementation detail. As an example, any data infrastructure software that uses non-trivial adapative scheduling to optimize concurrency and throughput famously has this property. It is also the primary reason things like database engines are effectively untestable until the code is nearly complete. In principle you could architect any software to be amenable to TDD, but for these cases the performance penalty implied by that architecture is so severe (literally on the order of 10x) that no one serious would design their software that way. In these cases, the same binary can pass testing on one machine and fail on another. It is a different discipline than classic TDD, and more critical as more software systems are implicitly distributed.