4 ms·

> Do Test Driven Development A lot of this is common sense stuff, but it might be better to replace this part with "Write tests." TDD is the kind of thing that

> Do Test Driven Development A lot of this is common sense stuff, but it might be better to replace this part with "Write tests." TDD is the kind of thing that sounds great in a blog post, but doesn't actually seem to work in the real world. At the very least, TDD is not a benchmark of a "mature software developer."

auspex 6y ago
TDD does work quite well if you follow it. Why do you think it doesn’t work in practice?
- 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.
villasv 6y ago
It “does actually seem to work” at my workplace.
- ramraj07 6y ago
  And so I have noticed teams and orgs which go for eternity without seeing effective examples of TDD in practice. Is there any resource which might help people like that (includes me?) something that shows TDD in real life scenarios maybe.
  - runawaybottle 6y ago
    There’s a world of difference between writing tests for a rest api endpoint vs other types of pesky code. Too big a difference really. Writing a bunch of tests for your utility methods like a DateFormatter is obvious, but if you shackle up other abstract implementations with tests and strict type checking, you can easily make a piece of unalterable code (maybe that’s the point). The question is, what is the value in doing that? Why shackle up all parts of your codebase when only a few parts are critical? I’ll admit that I also lack (and have lacked) guidance on testing.
  - villasv 6y ago
    I wouldn't know what resource to point without having a lot more context. And even if I had, I don't feel qualified to properly give you a diagnostic. All I can give is my anecdotal evidence. Most of our development teams apply TDD most of the time. We're working on a mature (5y) enough codebase to have a stable foundation. We do lots of integration testing and our testing is not without issues (it's slow, some of it is flaky, lots of test fixtures that are a pain to manage) but those issues do not come from TDD and are being dealt with piecemeal. The only downside of TDD I've personally witnessed in practice is tendency to write superfluous tests. They either don't test anything useful (e.g. things already guaranteed by types) or leak implementation details. But we encourage developers to improve those tests and the engineering team is overwhelmingly positive that TDD has been a net win for productivity. We try to deploy as much pair-programming as we can and the TDD methodology is specially improved by this. It helps dealing with loose ends from the task description or the technical kick-off and double-checking if the task acceptance criterion makes sense. If one developer of the pair has to take off halfway through, the most important bit is already agreed upon and the code review is much easier later on. Or if the pair-programming starts halfway through, the arriving developer can read the tests to catch up and help make the other tests pass.
tinco 6y ago
What world do you live in that TDD does not work in? I definitely do not do TDD all of the time, but when I do it works absolutely perfect. I'd pay any employee a 20% maturity bonus for applying TDD consistently. People are all getting mad about the "best practices" bit as if it's not just a fact. Does it hurt that much to admit that maybe you're not always the mature developer you'd want to be? I sure am not, I always get carried away writing cowboy code, maybe writing tests after, maybe not because I'm in a hurry and we can stand a bug or 2, and the CI/CD will catch any syntax errors anyway. The rules are simple though. You determine the best practices, you apply them, and your code will be more correct, it will be written faster, you will spend less time being confused, your final product will be closer to the specifications, and it will have less bugs. How could this be contentious? No way there's anyone out there that truly feels they wouldn't push less bugs to production if they always could and would apply TDD.
halfmatthalfcat 6y ago
TDD seems like something that exists only in theory. Every place I’ve worked, from startups to F500s, has talked about TDD but has never implemented it. I’ve been in the industry over a decade, maybe it’s just me.
toastal 6y ago
While not always applicable, I've found probably 80% of the time I feel “I should write a test”, I often a sign that I should leverage the compiler and model the data better in a way that doesn't allow the invalid state I would want to test. If you don't throw out some of the non-critical tests after your code is working, you're likely incurring a lot of tech debt in maintaining all of your tests that aren't really helping anymore.

auspex 6y ago

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

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.

villasv 6y ago

It “does actually seem to work” at my workplace.

ramraj07 6y ago
And so I have noticed teams and orgs which go for eternity without seeing effective examples of TDD in practice. Is there any resource which might help people like that (includes me?) something that shows TDD in real life scenarios maybe.
- runawaybottle 6y ago
  There’s a world of difference between writing tests for a rest api endpoint vs other types of pesky code. Too big a difference really. Writing a bunch of tests for your utility methods like a DateFormatter is obvious, but if you shackle up other abstract implementations with tests and strict type checking, you can easily make a piece of unalterable code (maybe that’s the point). The question is, what is the value in doing that? Why shackle up all parts of your codebase when only a few parts are critical? I’ll admit that I also lack (and have lacked) guidance on testing.
- villasv 6y ago
  I wouldn't know what resource to point without having a lot more context. And even if I had, I don't feel qualified to properly give you a diagnostic. All I can give is my anecdotal evidence. Most of our development teams apply TDD most of the time. We're working on a mature (5y) enough codebase to have a stable foundation. We do lots of integration testing and our testing is not without issues (it's slow, some of it is flaky, lots of test fixtures that are a pain to manage) but those issues do not come from TDD and are being dealt with piecemeal. The only downside of TDD I've personally witnessed in practice is tendency to write superfluous tests. They either don't test anything useful (e.g. things already guaranteed by types) or leak implementation details. But we encourage developers to improve those tests and the engineering team is overwhelmingly positive that TDD has been a net win for productivity. We try to deploy as much pair-programming as we can and the TDD methodology is specially improved by this. It helps dealing with loose ends from the task description or the technical kick-off and double-checking if the task acceptance criterion makes sense. If one developer of the pair has to take off halfway through, the most important bit is already agreed upon and the code review is much easier later on. Or if the pair-programming starts halfway through, the arriving developer can read the tests to catch up and help make the other tests pass.

tinco 6y ago

What world do you live in that TDD does not work in? I definitely do not do TDD all of the time, but when I do it works absolutely perfect. I'd pay any employee a 20% maturity bonus for applying TDD consistently. People are all getting mad about the "best practices" bit as if it's not just a fact. Does it hurt that much to admit that maybe you're not always the mature developer you'd want to be? I sure am not, I always get carried away writing cowboy code, maybe writing tests after, maybe not because I'm in a hurry and we can stand a bug or 2, and the CI/CD will catch any syntax errors anyway. The rules are simple though. You determine the best practices, you apply them, and your code will be more correct, it will be written faster, you will spend less time being confused, your final product will be closer to the specifications, and it will have less bugs. How could this be contentious? No way there's anyone out there that truly feels they wouldn't push less bugs to production if they always could and would apply TDD.

halfmatthalfcat 6y ago

TDD seems like something that exists only in theory. Every place I’ve worked, from startups to F500s, has talked about TDD but has never implemented it. I’ve been in the industry over a decade, maybe it’s just me.

toastal 6y ago

While not always applicable, I've found probably 80% of the time I feel “I should write a test”, I often a sign that I should leverage the compiler and model the data better in a way that doesn't allow the invalid state I would want to test. If you don't throw out some of the non-critical tests after your code is working, you're likely incurring a lot of tech debt in maintaining all of your tests that aren't really helping anymore.