Rigorous Engineering: Testing

I've been working for Google for about four months now, and I thought I'd reflect for a short time on how that has affected my software engineering practice. This post I want to concentrate on testing.

Testing is a concept that can strike fear into the most hardened of developers. Before working at Google, my testing regime was almost completely manual, with me writing small snippets of code to run a particular function, or manually hardcoding some values to simulate an error condition, or clicking around a GUI extensively. That worked quite well for me, and caught almost all my bugs before I released the code.

Unsurprisingly, Google's standards are a fair bit higher, and it's expected that code will be written in testable units wherever possible, and accompanied by unit tests. I've unit tested before, but not to the extent that is done here. On one hand, it's a real pain: I've laboured writing great code, thought hard about it to make sure it's correct, and I still need to prove it to my fellow engineers. On the other hand, unit tests I've written have caught a few silly mistakes I've made and they've better clarified the purpose of the code I'm writing. That latter consideration has helped a great deal when working in a team.

That's enough for now. Time to do some work.