4 ms·

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 af

by 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.

by felixge 16y ago

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.