4 ms·

Testing zealots never seem to understand that some errors are expensive and some are not. Testing should be a cost benefit analysis. I never waste my time wri

Testing zealots never seem to understand that some errors are expensive and some are not. Testing should be a cost benefit analysis. I never waste my time writing tests when the consequences of errors are cheap. Conversely, I always write tests when the consequences of errors are expensive.

gabriel 18y ago
I agree that with you that "some errors are expensive and some are not," but you don't know which category a bug falls under (cheap/expensive) until after the fact. So making that decision of what (or what not) to test isn't always so black and white.
- kschrader 18y ago
  Also, a bug might be cheap now, but when it breaks a year down the road and no one knows what happened, it's going to be a big problem.
- timcederman 18y ago
  It depends on the context. I've had some very simple fixes/updates I've wanted to put in production that I knew were incredibly low risk, and anything that could go wrong could not possibly be catastrophic, only to be vetoed and told to go through a very expensive testing process.
- richcollins 18y ago
  Yes you do. When you are making a prototype errors aren't expensive. When you are modifying code that customers are already paying you lots of money for errors are expensive.
fizx 18y ago
I always check to make sure a method roughly works, before moving on to the next one. Most of the time, this means either writing a unit test, or firing up the code and all of its dependencies, and clicking through it looking for bugs. If you are good at testing (like any skill, it requires experience), writing a unit test will be quicker than manually checking the code. So, perhaps, the cost isn't in writing the tests, but in acquiring the experience to test effectively. Also, and YMMV, I find writing code in a tests-first manner cuts my stress/frustration of coding by an order of magnitude. It greatly reduces the amount of context I have to keep in my head, so I'm not in the state where I can remember 90% of the information I need to effectively write this class.
- richcollins 18y ago
  > I always check to make sure a method roughly works, before moving on to the next one. Most of the time, this means either writing a unit test, or firing up the code and all of its dependencies, and clicking through it looking for bugs. In my experience, well factored methods are correct 95% of the time. When there is a bug you notice when you test things that exercise an entire host of methods at once. > Also, and YMMV, I find writing code in a tests-first manner cuts my stress/frustration of coding by an order of magnitude. It greatly reduces the amount of context I have to keep in my head, so I'm not in the state where I can remember 90% of the information I need to effectively write this class. Testing is not a good way to help with context. A good debugger and well written code is.
dasil003 18y ago
Also, it's important to remember that tests are code too. A test needs to stand the test of time just as code does--if the tests are too brittle then you're just creating busy work. However people who haven't tried methodologies like TDD or BDD shouldn't parrot this as justification for not writing tests. First you need to learn how to write tests, and how to write more testable code. Test-first is invaluable training for developing these skills. Once you have that experience you are better qualified to decide what constitutes useful testing. Frankly, I find the most value comes from basic sanity tests. Testing obscure edge cases of algorithms is often times not worth it because the mistake is made once and corrected. Having the test case is good (especially if written up front as an excercise in specification), but in many cases the chance that these things will break once fixed approaches 0.

gabriel 18y ago

I agree that with you that "some errors are expensive and some are not," but you don't know which category a bug falls under (cheap/expensive) until after the fact. So making that decision of what (or what not) to test isn't always so black and white.

kschrader 18y ago
Also, a bug might be cheap now, but when it breaks a year down the road and no one knows what happened, it's going to be a big problem.
timcederman 18y ago
It depends on the context. I've had some very simple fixes/updates I've wanted to put in production that I knew were incredibly low risk, and anything that could go wrong could not possibly be catastrophic, only to be vetoed and told to go through a very expensive testing process.
richcollins 18y ago
Yes you do. When you are making a prototype errors aren't expensive. When you are modifying code that customers are already paying you lots of money for errors are expensive.

fizx 18y ago

I always check to make sure a method roughly works, before moving on to the next one. Most of the time, this means either writing a unit test, or firing up the code and all of its dependencies, and clicking through it looking for bugs. If you are good at testing (like any skill, it requires experience), writing a unit test will be quicker than manually checking the code. So, perhaps, the cost isn't in writing the tests, but in acquiring the experience to test effectively. Also, and YMMV, I find writing code in a tests-first manner cuts my stress/frustration of coding by an order of magnitude. It greatly reduces the amount of context I have to keep in my head, so I'm not in the state where I can remember 90% of the information I need to effectively write this class.

richcollins 18y ago
> I always check to make sure a method roughly works, before moving on to the next one. Most of the time, this means either writing a unit test, or firing up the code and all of its dependencies, and clicking through it looking for bugs. In my experience, well factored methods are correct 95% of the time. When there is a bug you notice when you test things that exercise an entire host of methods at once. > Also, and YMMV, I find writing code in a tests-first manner cuts my stress/frustration of coding by an order of magnitude. It greatly reduces the amount of context I have to keep in my head, so I'm not in the state where I can remember 90% of the information I need to effectively write this class. Testing is not a good way to help with context. A good debugger and well written code is.

dasil003 18y ago

Also, it's important to remember that tests are code too. A test needs to stand the test of time just as code does--if the tests are too brittle then you're just creating busy work. However people who haven't tried methodologies like TDD or BDD shouldn't parrot this as justification for not writing tests. First you need to learn how to write tests, and how to write more testable code. Test-first is invaluable training for developing these skills. Once you have that experience you are better qualified to decide what constitutes useful testing. Frankly, I find the most value comes from basic sanity tests. Testing obscure edge cases of algorithms is often times not worth it because the mistake is made once and corrected. Having the test case is good (especially if written up front as an excercise in specification), but in many cases the chance that these things will break once fixed approaches 0.