4 ms·

Are you implying that TDD is bad in practice?

jakobegger 9y ago
The few times I've attempted to do test-driven development, I've ended up with code that passes the tests, but breaks in every possible way that is not specifically covered by a test.
- czardoz 9y ago
  Well, wouldn't it break in one more way if you don't have a test for it?
  - jakobegger 9y ago
    No. The problem is that people all too often see the passing tests and think, "Great, I'm done!". They don't take the time to evaluate whether they have thought of all cases.
    - czardoz 9y ago
      That doesn't mean they should not write tests for the cases they _can_ think about. It's better to have some test cases, rather than no test cases. Even if only the golden path is tested, that's still better than nothing.
      - jakobegger 9y ago
        Obviously, tests are a good thing and they are an important part of QA. I'm not arguing against automated tests. I'm merely trying to point out a weakness in the practice of "test driven development", where you write tests before you implement the functionality. Since you already have tests while you work, it's really easy to just treat them as a checklist, and once all tests pass it feels like you are done. But in reality, once the feature is done, that's when the hard QA work starts. You need to review the code, make sure you considered all error conditions, check if your assumptions hold throughout the execution of the program, ensure that your code is resilient to unexpected user input, etc. TDD might be a valuable part of a development/QA workflow, but just introducing TDD on its own is not going to make your product any better.
    - daliusd 9y ago
      When your product grows you normally shouldn't have time to evaluate all the cases. That's why you write unit-tests - so you wouldn't need to review all the cases when introducing new functionality. E.g. one of the product I was working on recently is made from several components. Couple components have 100+ unit-tests.

The few times I've attempted to do test-driven development, I've ended up with code that passes the tests, but breaks in every possible way that is not specifically covered by a test.

czardoz 9y ago
Well, wouldn't it break in one more way if you don't have a test for it?
- jakobegger 9y ago
  No. The problem is that people all too often see the passing tests and think, "Great, I'm done!". They don't take the time to evaluate whether they have thought of all cases.
  - czardoz 9y ago
    That doesn't mean they should not write tests for the cases they _can_ think about. It's better to have some test cases, rather than no test cases. Even if only the golden path is tested, that's still better than nothing.
    - jakobegger 9y ago
      Obviously, tests are a good thing and they are an important part of QA. I'm not arguing against automated tests. I'm merely trying to point out a weakness in the practice of "test driven development", where you write tests before you implement the functionality. Since you already have tests while you work, it's really easy to just treat them as a checklist, and once all tests pass it feels like you are done. But in reality, once the feature is done, that's when the hard QA work starts. You need to review the code, make sure you considered all error conditions, check if your assumptions hold throughout the execution of the program, ensure that your code is resilient to unexpected user input, etc. TDD might be a valuable part of a development/QA workflow, but just introducing TDD on its own is not going to make your product any better.
  - daliusd 9y ago
    When your product grows you normally shouldn't have time to evaluate all the cases. That's why you write unit-tests - so you wouldn't need to review all the cases when introducing new functionality. E.g. one of the product I was working on recently is made from several components. Couple components have 100+ unit-tests.