3 ms·

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

by 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.