4 ms·

I'm extremely happy to upvote first-hand TDD articles whenever I see them on here. There have been quite a few nice stories, both pro and con. I'd like to see

I'm extremely happy to upvote first-hand TDD articles whenever I see them on here. There have been quite a few nice stories, both pro and con. I'd like to see more folks talk about competitive advantage. After all, code just doesn't exist by itself -- it's supposed to do something. Does TDD help make technology make people's lives better? Or is it just a big PITA that ends up with more maintainable code? There's nothing wrong with that, but it's the kind of perspective question can be a critical success factor for startups.

felixge 16y ago
Regarding competitive advantages: We are working on a new feature that will allow us to encode video uploads while they are still uploading. This change will affect the most critical aspects of our code base and it's very easy to introduce subtle bugs. TDD is helping us to make fundamental changes like this without being too afraid of breaking things. I don't think we would undertake this feature if we didn't have the tests we do. (And TDD is the only way to get tests you really trust)
- ericwaller 16y ago
  (And TDD is the only way to get tests you really trust) Can you expand on this point? This is one aspect of TDD, which seems to focus most intensely on unit testing, I've never understood. Why wouldn't full-stack, acceptance testing be just as effective?
  - felixge 16y ago
    You can get value out of writing a test after the fact. But the value is higher for a test that you have written before the code because you have seen the test go from failing to passing. This way you know it will also fail if you break the code in the future. I also think writing the test before the feature will cause you to write better assert statements. If you write the test afterwards you'll tend to either assert everything (which leads to every test breaking on a small change), or to be horribly confused about what to assert and what not.
  - t_crayford 16y ago
    Full-stack tests will have a combinatorial explosion in the number of tests you have to write to get decent coverage, wheras isolated unit tests have a linear (with some constants) increase. Also full stack acceptance tests take ages to run (by definition they will be doing some complex computation). As mentioned above, if their test suite runs in under 5s, it gives a huge advantage. Imagine having light on your computer that goes red any time you make a mistake. They effectively have that.
- old-gregg 16y ago
  That to me sounds like a fairly generic reasoning for having tests. Moreover, your blog post reads more or less as "you must have tests", nothing about being "test-driven". I wonder if there were any TDD-specific advantages, and if they really outweigh boredom/inconvenience of having 1.6:1 test-to-code ratio.
Lewisham 16y ago
My feeling is that Behavior-Driven Development (which, as described below, is just TDD "done right") is what pushes this competitive advantage aspect. If you write down your user stories, and nothing is in those stories that says "Oh, that's cool!", you need to re-evaluate what you're doing. If the core requirements of your product doesn't do anything interesting, it's unlikely you have any competitive advantage. I've been thinking a lot about TDD and BDD and [insert letter here]DD recently as part of ongoing research. One thing that got lost when unit testing was proposed is that it's your requirements that stick with you through levels of abstraction... the specification (ie. what you implement in code and unit test) is a by-product of having to talk to a computer to express a model that meets those requirements. Unit testing, by itself, just validates that the model does what it says it does, but does nothing to assert whether the model actually does what it was supposed to do to meet the customer's requirements. That's what BDD ensures.
- jacques_chester 16y ago
  I think that the nice thing about BDD is that it reduces the gap between requirement gathering tools (use cases/scenarios, to be specific) and user acceptance or integration testing. But it doesn't banish the problems of inconsistent or incomplete requirements. And it doesn't drive away solution complexity exlosion as you descend into the code. And it certainly isn't as useful for diagnostic debugging on changes to the code. But it's in the user's language (-ish), so it's more likely to be funded and supported. That can only be a good thing.

felixge 16y ago

Regarding competitive advantages: We are working on a new feature that will allow us to encode video uploads while they are still uploading. This change will affect the most critical aspects of our code base and it's very easy to introduce subtle bugs. TDD is helping us to make fundamental changes like this without being too afraid of breaking things. I don't think we would undertake this feature if we didn't have the tests we do. (And TDD is the only way to get tests you really trust)

ericwaller 16y ago
(And TDD is the only way to get tests you really trust) Can you expand on this point? This is one aspect of TDD, which seems to focus most intensely on unit testing, I've never understood. Why wouldn't full-stack, acceptance testing be just as effective?
- felixge 16y ago
  You can get value out of writing a test after the fact. But the value is higher for a test that you have written before the code because you have seen the test go from failing to passing. This way you know it will also fail if you break the code in the future. I also think writing the test before the feature will cause you to write better assert statements. If you write the test afterwards you'll tend to either assert everything (which leads to every test breaking on a small change), or to be horribly confused about what to assert and what not.
- t_crayford 16y ago
  Full-stack tests will have a combinatorial explosion in the number of tests you have to write to get decent coverage, wheras isolated unit tests have a linear (with some constants) increase. Also full stack acceptance tests take ages to run (by definition they will be doing some complex computation). As mentioned above, if their test suite runs in under 5s, it gives a huge advantage. Imagine having light on your computer that goes red any time you make a mistake. They effectively have that.
old-gregg 16y ago
That to me sounds like a fairly generic reasoning for having tests. Moreover, your blog post reads more or less as "you must have tests", nothing about being "test-driven". I wonder if there were any TDD-specific advantages, and if they really outweigh boredom/inconvenience of having 1.6:1 test-to-code ratio.

Lewisham 16y ago

My feeling is that Behavior-Driven Development (which, as described below, is just TDD "done right") is what pushes this competitive advantage aspect. If you write down your user stories, and nothing is in those stories that says "Oh, that's cool!", you need to re-evaluate what you're doing. If the core requirements of your product doesn't do anything interesting, it's unlikely you have any competitive advantage. I've been thinking a lot about TDD and BDD and [insert letter here]DD recently as part of ongoing research. One thing that got lost when unit testing was proposed is that it's your requirements that stick with you through levels of abstraction... the specification (ie. what you implement in code and unit test) is a by-product of having to talk to a computer to express a model that meets those requirements. Unit testing, by itself, just validates that the model does what it says it does, but does nothing to assert whether the model actually does what it was supposed to do to meet the customer's requirements. That's what BDD ensures.

jacques_chester 16y ago
I think that the nice thing about BDD is that it reduces the gap between requirement gathering tools (use cases/scenarios, to be specific) and user acceptance or integration testing. But it doesn't banish the problems of inconsistent or incomplete requirements. And it doesn't drive away solution complexity exlosion as you descend into the code. And it certainly isn't as useful for diagnostic debugging on changes to the code. But it's in the user's language (-ish), so it's more likely to be funded and supported. That can only be a good thing.