3 ms·

I'm not completely against TDD. However, one thing I've found is bugs are caused by things you didn't think to write a test for (or write your code to handle s

I'm not completely against TDD. However, one thing I've found is bugs are caused by things you didn't think to write a test for (or write your code to handle sans tests). The mundane stuff I see in the vast majority of unit tests are things an experienced programmer almost never screws up. So how do you write a test for a case you couldn't foresee? My biggest argument in favor of writing tests is to ensure my code doesn't break relative to other people's code. There are many times I've encountered an update to a ruby gem with no major or minor version change that has broken a, usually implied, contract with my code. I say implied, because duck typers, at least what I've seen in the ruby world, tend to be slack about formalizing interfaces. I write tests to protect against that sort of thing.

youngian 17y ago
So how do you write a test for a case you couldn't foresee? You don't, but once you discover it, you write a regression test to make sure it doesn't come back. However, IANATDD, I am not a test-driven developer - I don't see any reason to be dogmatic, but I do think unit tests can be extremely valuable. So this answer might not be TDD-approved.
- InclinedPlane 17y ago
  "So how do you write a test for a case you couldn't foresee?" "You don't, but once you discover it, you write a regression test to make sure it doesn't come back." Sure, that's SOP in any good dev. house that does testing. But you've failed to address a key weakness in TDD. The real question is how do you discover these sorts of defects given that a single developer writing in a TDD style is unlikely to do so? TDD is clearly not a cure all, and this is a major weakness of it. Other development techniques, many of which can complement TDD, such as formal code reviews and beta testing can do a better job of getting you to higher product quality than TDD alone.
  - chuckm 17y ago
    "TDD is clearly not a cure all" Who said it was?
    - binspace 17y ago
      Exactly!! There is no such thing as a cure all. Anybody angry over a technique that does not solve all problems is clearly suffering from the Silver Bullet Syndrome.
      - devinj 17y ago
        What? Why does something have to be perfect for somebody to get angry over it?
        binspace 17y ago
        Not exactly sure what you are asking. I mainly meant any tool you use will not solve all of your problems. Pretty basic common sense, IMO.
binspace 17y ago
TDD does not claim to fix all of your bugs. You often do not need to theoretically prove your software is correct, so you don't need to have you unit tests test all possible contexts (e.g. handling disk failure vs. any other error when rendering a web page). That is what abstraction is for. TDD does force you to think about the interface of your abstraction, however. If it is painful to write (or maintain) the test, then that is a good indication that the abstraction is wrong or not being properly tested. Don't be afraid of deleting tests when they are not useful. I often find that these unanticipated bugs are often due to incorrect abstractions. To fix it, create the correct abstraction and test it. It is also simply faster to develop in larger projects than creating the state that would test your unit. For example, you could make a change, manually refresh the page, and debug or write the test and make it pass. You also get the benefit of regression testing. Note that the narrower your unit, the less likely it will be useful for regression purposes. I often find that when beginning a project, my units are smaller. As abstractions are built, the nonessential tests are deleted and future tests are built upon abstractions that I care about.
erso 17y ago
For me, I don't always know what the edge cases could be until I write them down. Writing tests allows me to get a clearer picture of what kind of coverage I have.
- binspace 17y ago
  Another nice thing is you can read what the edge cases are going to be, rather than having to remember them all of the time.
lucifer 17y ago
"bugs are caused by things you didn't think to write a test for" Bugs are not caused because of missing test cases, but it is perhaps true that the same thought process that "causes" bugs is also responsible for not coming up with a test case that would find the bug. On the other hand, writing buggy test code (enter into meta madness :) is responsible for causing bugs to metamorphose into 'features'.
grandpa 17y ago
> So how do you write a test for a case you couldn't foresee? TDD is a design technique, not a testing technique.

youngian 17y ago

So how do you write a test for a case you couldn't foresee? You don't, but once you discover it, you write a regression test to make sure it doesn't come back. However, IANATDD, I am not a test-driven developer - I don't see any reason to be dogmatic, but I do think unit tests can be extremely valuable. So this answer might not be TDD-approved.

InclinedPlane 17y ago
"So how do you write a test for a case you couldn't foresee?" "You don't, but once you discover it, you write a regression test to make sure it doesn't come back." Sure, that's SOP in any good dev. house that does testing. But you've failed to address a key weakness in TDD. The real question is how do you discover these sorts of defects given that a single developer writing in a TDD style is unlikely to do so? TDD is clearly not a cure all, and this is a major weakness of it. Other development techniques, many of which can complement TDD, such as formal code reviews and beta testing can do a better job of getting you to higher product quality than TDD alone.
- chuckm 17y ago
  "TDD is clearly not a cure all" Who said it was?
  - binspace 17y ago
    Exactly!! There is no such thing as a cure all. Anybody angry over a technique that does not solve all problems is clearly suffering from the Silver Bullet Syndrome.
    - devinj 17y ago
      What? Why does something have to be perfect for somebody to get angry over it?
      - binspace 17y ago
        Not exactly sure what you are asking. I mainly meant any tool you use will not solve all of your problems. Pretty basic common sense, IMO.

binspace 17y ago

TDD does not claim to fix all of your bugs. You often do not need to theoretically prove your software is correct, so you don't need to have you unit tests test all possible contexts (e.g. handling disk failure vs. any other error when rendering a web page). That is what abstraction is for. TDD does force you to think about the interface of your abstraction, however. If it is painful to write (or maintain) the test, then that is a good indication that the abstraction is wrong or not being properly tested. Don't be afraid of deleting tests when they are not useful. I often find that these unanticipated bugs are often due to incorrect abstractions. To fix it, create the correct abstraction and test it. It is also simply faster to develop in larger projects than creating the state that would test your unit. For example, you could make a change, manually refresh the page, and debug or write the test and make it pass. You also get the benefit of regression testing. Note that the narrower your unit, the less likely it will be useful for regression purposes. I often find that when beginning a project, my units are smaller. As abstractions are built, the nonessential tests are deleted and future tests are built upon abstractions that I care about.

erso 17y ago

For me, I don't always know what the edge cases could be until I write them down. Writing tests allows me to get a clearer picture of what kind of coverage I have.

binspace 17y ago
Another nice thing is you can read what the edge cases are going to be, rather than having to remember them all of the time.

lucifer 17y ago

"bugs are caused by things you didn't think to write a test for" Bugs are not caused because of missing test cases, but it is perhaps true that the same thought process that "causes" bugs is also responsible for not coming up with a test case that would find the bug. On the other hand, writing buggy test code (enter into meta madness :) is responsible for causing bugs to metamorphose into 'features'.

grandpa 17y ago

> So how do you write a test for a case you couldn't foresee? TDD is a design technique, not a testing technique.