Should I write unit tests? Yes and I’ll tell you why.(blog.hubstaff.com)
blog.hubstaff.com
Should I write unit tests? Yes and I’ll tell you why.
http://blog.hubstaff.com/why-you-should-write-unit-tests/
5 comments
I might have to use that the next time I pitch a client on the virtues of unit testing.
First step of unit testing is picking the correct language. Static analysis will eliminate the need for whole class of errors. Then apply code contracts. Consider extending your static analysis package of choice to add rules specific to your application. As the last step write unit tests to cover your core business logic - something the computer can't figure out for you. Realizing that unit tests are basically poor man's static analysis is the first step to becoming better at writing them.
If I have projects which were written without tests because I was an idiot and didn't know "running it and seeing that it works" counted as a test, should I go back and write tests for what I already have or start testing on new code only?
I recommend the following strategy:
1. Don’t ship any new features without writing unit tests for them first.
2. These new features most likely rely on parts of existing code so write a few tests for that existing code with each new feature.
3. If something breaks in production write a test for it at the time that you fix it.
Little by little you’ll increase your code coverage without grinding development to a halt.
1. Don’t ship any new features without writing unit tests for them first.
2. These new features most likely rely on parts of existing code so write a few tests for that existing code with each new feature.
3. If something breaks in production write a test for it at the time that you fix it.
Little by little you’ll increase your code coverage without grinding development to a halt.
ok thanks.
Possible counter point: while the unit-tester is busy writing perfect software. I'll be lazy... and perhaps I'll beat them to market and will use the resulting money to perfect the software.
Countering your counter point: while you're busy answering support calls and working through bugs that weren't caught in functional tests, I'll be delighting customers with software that works and sleeping better at night in a less stressful work environment because we've done everything we can to ensure our software is as good as it can be.
I actually thought the same way you do until just recently. Once you get into the flow of writing unit tests, you'd be surprised how little time it takes, and how effective TDD can be. It helps me stay focused, and structure programs better. I can't say if it actually has slowed my development time at all, when you take into account fixing bugs found in functional testing.
I actually thought the same way you do until just recently. Once you get into the flow of writing unit tests, you'd be surprised how little time it takes, and how effective TDD can be. It helps me stay focused, and structure programs better. I can't say if it actually has slowed my development time at all, when you take into account fixing bugs found in functional testing.
In my experience this strategy only works with small projects. Projects with any level of complexity will have you running from fire to fire and it will impede your forward progress. Developer retention and customer happiness will suffer. I'd be happy to compete against such a company. ;)
Test often, test soon
good article
"Do you think the customer is going to get angry if you explain that part of your development process is to execute the code you just wrote to make sure it doesn’t crash? If the answer to that is “no, of course not, that’s ridiculous” then you also have the answer to whether or not a customer would care if you happened to automate that process."