I’ve been doing some fiddly coding for the OpenAddresses project. It reminds me of one of my favorite engineering interview questions. “How do you know your code works?”

The arrogant candidate says “I’m smart so I know my code is good”. That’s certainly a bad sign, although sometimes they’re right. Slightly wiser responses are “I run it and look closely” or “I trace the code and make sure it works like I expect”. Better, but too manual. The truly enlightened say “I have an automated test suite” and then you’re off to the real questions about how to test code properly.

I have a deep distrust of code. Software is organic, unpredictable, chaotically complex. It’s difficult enough to understand what the code you write now is likely to do right now with expected inputs. But hostile inputs, or a weird environment, or the same code a year from now, or the slightly modified open source contribution in some fork somewhere? Forget it. That’s why automated tests are so valuable. It’s a way to demonstrate the code is doing what you expect it to.

Writing good tests is hard, almost as hard as writing good code. Modern environments have a lot of testing tools you should learn. From language unit test frameworks to mock objects for servers to fuzz testing to various continuous integration systems for functional tests. GitHub projects have the miracle which is Travis CI, free no-fuss continuous build and test for any open source project. It’s amazing.

So until software correctness proofs become a real tool we can use in real production code, ask yourself how you know your code is going to work. If you’re honest, you probably don’t. But some testing will certainly help give you at least a little confidence.