3 ms·

I'm sorry, I must not have been clear before. I'm not trying to assert or to prove that TDD "guarantees an improvement in the quality of our code and the speed

by lyudmil 16y ago

I'm sorry, I must not have been clear before. I'm not trying to assert or to prove that TDD "guarantees an improvement in the quality of our code and the speed of delivery" and I regret that it's come off like that. I'm saying that it's worth investigating with rigor and trying to steer this discussion towards specifics. As I implied in my first post, I disagree with the OP's opinions specifically because it stomps out the discussion I want to have here. As you've implied, there are probably situations in which TDD is useful. There are situations where TDD is detrimental. The discussion I want to have is to define and support as precisely as possible when it's good to use TDD and when you should not. This isn't a call to bring up objections that I can shoot down - I'm genuinely interested in knowing because not knowing (or at least having a very good idea) is unprofessional (in my opinion, obviously). Anyone who disagrees TDD is "a mixed bag" is unprofessional (as you pointed out - "No silver bullet!"). What I asserted originally was about what's in that bag. I asserted that not knowing is unprofessional because then you're advocating or dismissing a practice without evidence.

gte910h 16y ago
Yeah, I didn't catch that earlier: IMO, TDD shines when: You're doing completely data oriented tests You're doing things that have to work under changing (non-GUI) conditions without crashing You're using embedded/system level controllers which need to be functioning under all inputs. You have a moderately data intensive app and a moderately complex GUI action required to put in edge cases. You have a automation framework at your disposal to push buttons and capture window contents. You can structure your project into backend library/front end GUI using library. TDD lacks luster when: You have lots of GUIs and no automation framework You have poor definition of system behavior (proofs of concept based apps sometimes have this) You have an embedded target with limited debugger support You have physical switches in your application You have apps with lots of heterogeneously structured mutli-threading (the more conditionally compiled/run code, the worse the heisenbugs get), especially with a strong GUI component.

by lyudmil 16y ago

gte910h 16y ago

Yeah, I didn't catch that earlier: IMO, TDD shines when: You're doing completely data oriented tests You're doing things that have to work under changing (non-GUI) conditions without crashing You're using embedded/system level controllers which need to be functioning under all inputs. You have a moderately data intensive app and a moderately complex GUI action required to put in edge cases. You have a automation framework at your disposal to push buttons and capture window contents. You can structure your project into backend library/front end GUI using library. TDD lacks luster when: You have lots of GUIs and no automation framework You have poor definition of system behavior (proofs of concept based apps sometimes have this) You have an embedded target with limited debugger support You have physical switches in your application You have apps with lots of heterogeneously structured mutli-threading (the more conditionally compiled/run code, the worse the heisenbugs get), especially with a strong GUI component.