3 ms·
> writing code takes double the time when you also have to write the tests this time is more than made up for by the usual subsequent loss of debugging, refact
by pmarreck 4y ago
> writing code takes double the time when you also have to write the tests
this time is more than made up for by the usual subsequent loss of debugging, refactoring and maintenance time, in my experience, at least for anything actively being used and updated
- wenc 4y agoIn theory, I agree. In practice, at least for my projects, the results are mixed.
- tsimionescu 4y agoYes, if you were right about the requirements, even if they weren't well specified. But if it turns out you implemented the wrong thing (either because the requirements simply changed for external reasons, or because you missed some fundamental aspect), then you wouldn't have had to debug, refractor or maintain that initial code, and the initial tests will probably be completely useless even if you end up salvaging some of the initial implementation.
- twic 4y agoNo, that's a separate issue, that eschewing TDD doesn't help you with. With TDD, the inner programming loop is: 1. form a belief about requirements 2. write a test to express that belief 3. write code to make that test pass Without TDD, the loop is: 1. form a belief about requirements 2. write code to express that belief 3. futz around with manual testing, REPLs, and after-the-fact testing until you're sufficiently happy that the code actually does express that belief And in my experience, the former loop is faster at producing working code.
- minimeme 4y agoThat's my experience also! It's all about faster feedback and confidence the tests provide.
- ipaddr 4y agoIt usually works out like.. form a belief about a requirement write a test test fails write code test fails add debug info to code test fails no debug showing call code directly and see debug code change assert test fails rewrite test test succeed output test class data.. false positive checking null equals null rewrite test test passes forget original purpose and stare at green passing tests with pride.
- xxs 4y ago> add debug info to code On a more serious note: just learn to use a debugger, and add asserts, if need be. To me TDD only helps having something that would run your code - but that's pretty much it. If you have other test harness options, I fail to see the benefits outside conference talks and books authoring.
- pmarreck 4y agomy professional opinion is that having to resort to a debugger is a bad-design, bad-testing code smell
- laserlight 4y agoYes, so much this. I don’t really understand how people could object to TDD. It’s just about putting together what one manually does otherwise. As a bonus, it’s not subject to biases because of after-the-fact testing.
- pjmlp 4y agoTest the belief of recovery from a network split in distributed commit.
- laserlight 4y agoI don't get the point. Is it something not testable? If it's testable, it's TDD-able.
- pjmlp 4y agoTDD sales pitch is not to write any code without an existing test.
- thrwyoilarticle 4y ago>at least for anything actively being used and updated This implies that the strength of the tests appears when it's modified? Like the article says, TDD doesn't own the concept of testing. You can write good tests without submitting yourself to a dogma of red/green, minimum-passing (local-maximum-seeking) code. Debating TDD is tough because it gets bogged down with having to explain how you're not a troglodyte who writes buggy untested code. And - on a snarkier note - this is a better argument against dynamic typing than for TDD.