4 ms·

I think the only reason TDD works as well as it does is because it forces you to _actually_ write the tests. If you write the tests after the code, it would be

by NateDad 14y ago

I think the only reason TDD works as well as it does is because it forces you to _actually_ write the tests. If you write the tests after the code, it would be perfectly fine.... except no one ever (hyperbole) writes tests after the code, because management/sales/support sees that the code works in the general case, and now insists you work on the next feature and/or you get excited about another feature and don't want to write boring tests. If you write the test first, that can't happen, because you haven't written the actual code yet.

scott_w 14y ago
I think it's actually worse than that: people who write tests after code just write their tests to "verify" that the code is doing what the code is doing. So, the code provides a list of numbers 1, 2, 5. Non-TDD would code a test that verifies the list is indeed 1, 2, 5. However, the business wanted the list in reverse order: 5, 2, 1. TDD would force the developer to state this up-front. A non-TDD developer is more reluctant to change the code, since "it passes the test!" I've done this, although I like to think I'm quite happy to rewrite something if it's not good enough (or just wrong).
- markhelo 14y ago
  I am not sure I agree with it being worse. Would you rather have code with no tests or code with tests even if they do verify what it is doing? Most regression tests are brittle because they never change and get hardened. In my previous life, I was majorly behind model-based testing which is very similar to concepts of TDD in that it forces people to think of your entire component and then it generates tests or can walk through your reference implementation to verify your actual code. However in smaller companies, I personally feel that it is important to first test the right "it" before building it right. (As Google Engineering Director Alberto Savoia used to put it). No one is advocating releasing broken stuff, but whats the point of releasing something perfectly tested that no one wants? I think the answer lies somewhere in the continuum. And in my own startup (wello) we do go back and write tests, because testing everything manually does hurt once the feature is working well and users actually want what you are building. So we do carve out time and write tests and often times then build it right. You could argue that this is inefficient, but I could also argue that for many features we removed because users did not want them, we saved the time needed in upfront TDD.
  - stcredzero 14y ago
    > Most regression tests are brittle because they never change and get hardened. Regression tests should get refactored at the same time by the same tool that refactors the rest. Code changes should be handled the same way.
    - markhelo 14y ago
      Agreed. I was only saying that mosts tests are written to codify what is expected not that they should not be changed with changing code.
re_todd 14y ago
This certainly corresponds to me personally. I used to put off testing, thinking I'd have more time later, but then I'd add "just one more" feature before doing testing, over and over again. The list of tests I needed to write would grow until it seemed overwhelming, making me somewhat depressed thinking about all the testing I still needed to do. Since shifting to TDD, I get into the habit of writing tests before writing code, and the depressing test-related feelings are gone, which makes me a much happier programmer.
EvilTerran 14y ago
While that's undoubtedly part of it, I'd say there's definitely other advantages too. For instance, as danso says at [http://news.ycombinator.com/item?id=5332448 http://news.ycombinator.com/item?id=5332448], it forces orthogonality, because you have to think how a function can be tested independently of the external objects that may use it; if you have to write your code with automated tests in mind, it's almost inevitably going to be more modular, because poor modularity turns writing those tests into a massive pain. Also, the tests can act as something like a formal specification; in the process of writing tests, unspecified edge cases may become apparent that weren't noticeable in the natural-language spec.
philwelch 14y ago
If that works for you, it's fine. For me, sometimes I write tests first, sometimes last, but always in the same commit as the feature. If I'm working with someone that's all I can really ask of them, and if you adopt the same practice you can protect your code from inept managers and salesmen.

by NateDad 14y ago

scott_w 14y ago

I think it's actually worse than that: people who write tests after code just write their tests to "verify" that the code is doing what the code is doing. So, the code provides a list of numbers 1, 2, 5. Non-TDD would code a test that verifies the list is indeed 1, 2, 5. However, the business wanted the list in reverse order: 5, 2, 1. TDD would force the developer to state this up-front. A non-TDD developer is more reluctant to change the code, since "it passes the test!" I've done this, although I like to think I'm quite happy to rewrite something if it's not good enough (or just wrong).

markhelo 14y ago
I am not sure I agree with it being worse. Would you rather have code with no tests or code with tests even if they do verify what it is doing? Most regression tests are brittle because they never change and get hardened. In my previous life, I was majorly behind model-based testing which is very similar to concepts of TDD in that it forces people to think of your entire component and then it generates tests or can walk through your reference implementation to verify your actual code. However in smaller companies, I personally feel that it is important to first test the right "it" before building it right. (As Google Engineering Director Alberto Savoia used to put it). No one is advocating releasing broken stuff, but whats the point of releasing something perfectly tested that no one wants? I think the answer lies somewhere in the continuum. And in my own startup (wello) we do go back and write tests, because testing everything manually does hurt once the feature is working well and users actually want what you are building. So we do carve out time and write tests and often times then build it right. You could argue that this is inefficient, but I could also argue that for many features we removed because users did not want them, we saved the time needed in upfront TDD.
- stcredzero 14y ago
  > Most regression tests are brittle because they never change and get hardened. Regression tests should get refactored at the same time by the same tool that refactors the rest. Code changes should be handled the same way.
  - markhelo 14y ago
    Agreed. I was only saying that mosts tests are written to codify what is expected not that they should not be changed with changing code.

re_todd 14y ago

This certainly corresponds to me personally. I used to put off testing, thinking I'd have more time later, but then I'd add "just one more" feature before doing testing, over and over again. The list of tests I needed to write would grow until it seemed overwhelming, making me somewhat depressed thinking about all the testing I still needed to do. Since shifting to TDD, I get into the habit of writing tests before writing code, and the depressing test-related feelings are gone, which makes me a much happier programmer.

EvilTerran 14y ago

While that's undoubtedly part of it, I'd say there's definitely other advantages too. For instance, as danso says at [http://news.ycombinator.com/item?id=5332448 http://news.ycombinator.com/item?id=5332448], it forces orthogonality, because you have to think how a function can be tested independently of the external objects that may use it; if you have to write your code with automated tests in mind, it's almost inevitably going to be more modular, because poor modularity turns writing those tests into a massive pain. Also, the tests can act as something like a formal specification; in the process of writing tests, unspecified edge cases may become apparent that weren't noticeable in the natural-language spec.

philwelch 14y ago

If that works for you, it's fine. For me, sometimes I write tests first, sometimes last, but always in the same commit as the feature. If I'm working with someone that's all I can really ask of them, and if you adopt the same practice you can protect your code from inept managers and salesmen.