Summary: testing is good… no, great

I’ve been working on a website based on node.js for about 1.5 years now. I didn’t create the site, and when I got it, I saw that 1) it had a very extensive code base and 2) a small number of tests had been written relative to the size of the code base.

It’s understandable; I can see the temptation to avoid coding tests when you’re not really sure if the code will just end up being thrown away. The time spent writing tests could (perhaps) be more productively spent adding new, vital features.

In any case, I decided I needed more code coverage, because I hate it when I fix a bug or add some feature, only to find that it has been broken in some obscure way months later. Having a large suite of tests to run won’t always protect against this kind of thing, but it does help some.

Most recently, I’ve been writing a new, fairly complicated feature. It’s nearing completion. I’ve been writing unit-like tests all along, but I decided in the end that it would be worth writing some integration-like tests that run against a working dev server. The second integration test that I wrote kept failing – immediately. It looked okay. I kept debugging it until I was nearly sure that it should pass. So I went back and looked at my server code. Voilà! My server code was at fault. Nerds! To be honest, I rarely find that tests so quickly uncover a bug. But it happens often enough, and it gives me a warm fuzzy feeling about testing!