Testing in Code

Test Driven Development feels backwards. As a programmer, it feels very strange to write tests that you know will fail. Furthermore, it feels even more strange to figure out the logic for the function you're writing before you are allowed to write any actual code. I'm used to figuring out the logic as I'm writing, rather than before.

However, as strange as it feels: it's a step in the right direction for a stronger code base.

How it helps:

Particularly in environments with multiple programmers, small changes can cause huge errors.

In a recent project, I made a change to change the domain name when the user switches from English to French. Unfortunately: not every person does JavaScript the same way. Where I prefer to do <a href="javascript:[function]">, another developer on my team prefers to do <a href="#" onclick="[function]">. This is fine, but my fix caused huge problems due to the other developers code. Entire ajax calls were fried in the process. I didn't think to test random links on the page, cause my code didn't touch them, and of course everyone uses the first method of calling javascript via a link... but I should have. Automated testing doesn't think, it just tests. I rationalized why I didn't need to test something to save time. Automated testing doesn't need to save time.

If we had tests (in this case Selenium tests would do well), then I'd have noticed the problem immediately and would have fixed it before I checked in my changes, or perhaps immediately after if the tests fire off on commit. My changes wouldn't have gone live for half an hour and our CEO would not have had another mini heart attack, and further more: I would not look as stupid.

I think the biggest problem is that tests feel unproductive, when in fact, they probably save more time than writing the code itself, as tests are largely for the rest of your team, and will continue to help months down the line when you forget that you even wrote that code.