We're big on automated testing here at Devver, but I know a lot of companies aren't as into it. There's been plenty written about all the reasons you should be writing tests, but over the next week or so, I'll give you some tips on how to get started (and if you've already got some tests, how to improve and expand your test suite).
I can't claim to have come up with these best practices, so I'll litter this post with links to those resources that have taught me something.
A quick word about terminology. When I say "tests" I mean any type of automated tests, which may include unit, functional, integration or any other types of tests. When I say "production code" I simply mean the code goes into the actual product - i.e. the code being tested.
Tip 1: You'll probably suck at testing
Writing tests can be frustrating at first. It is usually a lot harder and more time consuming than you'd expect. Unfortunately, some developers assume that the cost of writing tests is fixed and conclude that the benefits can't possible justify the time spent - so they quit writing tests.
Writing test code is an art unto itself. There are a whole new set of tricks and skills to learn and it's difficult to do correcty right away. Stick with it. The better you get, the faster you'll write tests, and the more your tests will pay off.
subscribe to our feed