The other day I was thinking about Rich Hickey’s keynote at last year’s Conj. He goes into how the literal maps (or hashes or hashmaps or however a language prefers to call them) are really functions too. A function in maths is a mapping between sets and that’s what maps are.

Then that makes functions we normally write are just like that too, except the mappings are more abstract and defined through code. Because the mappings are so complex and indirect, we write tests to check (automated) that the mapping we defined through code is correct.

Obviously defining the exact mappings for every possible combination of the input set(s) is not feasible (that’d be a map, the end). But if “all” is not possible then how much is? What exactly is the absolute minimum amount of test( case)s that’s useful?

I think that first of all, any amount of tests is better than no tests. But if talking about ideals, that’d be testing the edges. That is every conditional branch tested. Which would hopefully result in the famed “100% code coverage”, unless there is code that can’t be reached. Which shouldn’t be.

Things get really tricky with hidden conditions though. Some conditions might be really hard to test (or even anticipate) if input comes from the outside world – and guess what it pretty much always does.

My thumb of rule (oh wait) is writing a test for every conditional at first and then for the stuff I missed when things break. But then actually the pinky finger rule is that tests slow me down a lot, so I iterate fast and write the tests when the “business rules” solidify more or when bugs get in the way.