3 ms·

This makes me incredibly sad. Once upon a time I wrote a story about a person who didn't use TDD and how he suffered: http://ryanbigg.com/2010/02/congratulatio

This makes me incredibly sad. Once upon a time I wrote a story about a person who didn't use TDD and how he suffered: http://ryanbigg.com/2010/02/congratulations/ http://ryanbigg.com/2010/02/congratulations/

mistermann 16y ago
It's a great story, but the advocacy of TDD was lost on me. As a person that is genuinely interested in why TDD is so important but doesn't understand the importance or practice it, could you point me to an article that explains it? I'm a developer who really doesn't have serious problems with bugs. Maybe I write my code a bit slower as I am always thinking about edge cases as I go, but everyone keeps telling me I have to write all these tests, but for what? Is it mostly for the following developers? I suppose that makes sense. But then, I've inherited projects where I had to throw 50% of the code away, and all of the tests, because it was hotshot young developers who were hip to all the new things, but couldn't code their way out of a paper bag. I see you point, but I think some sort of a reasonable balance has to be reached here.
- thorax 16y ago
  Well, it has a lot of uses. For developers that are new to a largish code base, it can help them ensure they don't break important subsets (as would any good unit testing strategy). But also it proves to be quite handy when you have a really complex system that grows over time. When you go to refactor it to keep it evolving and working, the tests throughout (while costly to maintain) give you more reassurance that you didn't wreck the world. TDD adds costs but reassurance that you don't break major things during a refactor. It can get a bit cumbersome at times, but it's hard for me to avoid seeing the value for long-lived code (i.e. non-prototypes) and/or shared code. It's not for everyone or everything, but I think it's pretty reactionary for anyone to say it's not a useful process to have in your toolbox. For example, I recommend TDD for cases where you're making a public API to unknown people. It's much more likely you'll break some unknown importance nuance in a refactor unless you have a good number of comprehensive unit tests. If you can generate those in some other fashion, awesome-- but TDD puts you ahead of the game there. For me, I also don't have the best long-term memory on details given how many vastly different projects/technologies I work on, so TDD is basically encoding that memory for me so I don't make multi-tasking mistakes for problems I've already solved a month or few weeks ago and helps pass on that memory to people who inherit that code later. I'm an aggressive commenter for that reason, too, but nothing helps you keep cross-component issues solid than unit tests designed to be the canary in the coal mine when you break something in a refactor.

mistermann 16y ago

It's a great story, but the advocacy of TDD was lost on me. As a person that is genuinely interested in why TDD is so important but doesn't understand the importance or practice it, could you point me to an article that explains it? I'm a developer who really doesn't have serious problems with bugs. Maybe I write my code a bit slower as I am always thinking about edge cases as I go, but everyone keeps telling me I have to write all these tests, but for what? Is it mostly for the following developers? I suppose that makes sense. But then, I've inherited projects where I had to throw 50% of the code away, and all of the tests, because it was hotshot young developers who were hip to all the new things, but couldn't code their way out of a paper bag. I see you point, but I think some sort of a reasonable balance has to be reached here.

thorax 16y ago
Well, it has a lot of uses. For developers that are new to a largish code base, it can help them ensure they don't break important subsets (as would any good unit testing strategy). But also it proves to be quite handy when you have a really complex system that grows over time. When you go to refactor it to keep it evolving and working, the tests throughout (while costly to maintain) give you more reassurance that you didn't wreck the world. TDD adds costs but reassurance that you don't break major things during a refactor. It can get a bit cumbersome at times, but it's hard for me to avoid seeing the value for long-lived code (i.e. non-prototypes) and/or shared code. It's not for everyone or everything, but I think it's pretty reactionary for anyone to say it's not a useful process to have in your toolbox. For example, I recommend TDD for cases where you're making a public API to unknown people. It's much more likely you'll break some unknown importance nuance in a refactor unless you have a good number of comprehensive unit tests. If you can generate those in some other fashion, awesome-- but TDD puts you ahead of the game there. For me, I also don't have the best long-term memory on details given how many vastly different projects/technologies I work on, so TDD is basically encoding that memory for me so I don't make multi-tasking mistakes for problems I've already solved a month or few weeks ago and helps pass on that memory to people who inherit that code later. I'm an aggressive commenter for that reason, too, but nothing helps you keep cross-component issues solid than unit tests designed to be the canary in the coal mine when you break something in a refactor.