To test or not to test
I read a great article on testing written by James Golick. There’s always a debate about doing unit testing or not. Most of the we-don’t-write-tests-because-we-don’t-have-time-to-do-it evangelists say that they have to implement features and release the product and that’s the reason they don’t write tests. I’ve felt this too, but that was before starting to write tests. It’s just like your old Honda, why buy a new one what the old one works so well.

I started writing tests when I begun working with Ruby and Rails. Before this, I worked in C, C++, Java, where you have to look for a testing framework, then learn how to use it, and then using it. Probably that’s why I’ve never done it. But when I started to learn Rails, and Ruby, and I saw the unit testing embedded into the language itself, it became so obvious and easy to try it. It’s hard to change the old habits. Even now when working on a new project I want to keep implementing features and never look back. But with mind discipline, I keep reminding myself that I need to write tests. Test-driven or not, during development it’s great to have tests. It’s assuring and comforting. And you’ll even sleep better at night.

We don’t need tests
Even though it’s been proved that writing tests is good, a lot of developers never write tests. And they always say that they don’t have time to do it, that they have to implement features, that they have to release on time, that they feel much comfortable with manual testing. Correct me if I’m wrong, but all the developers that started to write tests changed their mind about testing. And they keep writing tests for everything they do. To all the other developers: I don’t want to argue with you. I just have a suggestion: for your next project, do write tests and do it for a while. Never say Subaru or Honda is not a great car unless you’ve driven one. It’s the same thing. Never say testing is not good unless you’ve tried it. And not for a day or two. Do it for a couple of months. If you still feel it doesn’t help you than it’s fine. But unless you’ve tried it, don’t say it it’s not good.

Writing efficient tests
It takes some time to write efficient tests. The more you write tests, the better your tests are. Don’t expect to write efficient tests from the beginning. Just keep doing it, and you’ll see that your tests get better in time.

Testing is great for startups
When you have a small team, you can’t afford to spend time on testing…or better, on manual testing. Manual testing takes more and more time as you add features. So you have two options:

• having a testing team, which means more money, and it’s a bad idea for startups;
• developers test manually, which takes more time as you add features.

Having tests which run automatically saves you a lot of time, because you write a test, then a feature (or viceversa), and then another test, and another feature, one step at a time. At the end of the day you’ll have less features, but all of them are tested, and protected from now on by regressions. And this saves a lot of time you’d spend later on debugging and bug-fixing.

Another good thing when you have tests is that you can refactor your code more often and with more confidence. That’s because you have a suite of regression tests to back you up. And every time you refactor something, you can run the tests to see if you broke something. And the chances there’s a hidden bug which will appear on you live app decrease.