Tagged: testing
Testing: How Not to Fire Ze Missiles
(The following is an adaptation of a talk I did concerning how to focus your testing and how to better conceptualize what kinds of testing to focus on.)
A lot of companies and a lot of developers like to talk about what kinds of testing they’re doing. But here’s a dirty little secret that the software industry won’t tell you: It’s much more common that you’ll be working at a company where very little of the code is regularly tested outside of production. I’m talking single digits code coverage bad. Many developers neglect tests, but a big part of that is because they’re unsure how to properly approach testing.
End Goals
When approaching the concept of testing your code, you should ultimately be thinking about the end goals that you want your code to accomplish. I like to focus this into three areas:
- Your code should do what you think it does.
- Your code shouldn’t do what you don’t think it does.
- You shouldn’t allow your code to make the same mistakes twice.
While most software doesn’t act in a life-critical role, it’s easiest to break these down by considering:
“If I make a mistake, will my code ‘fire ze missiles’?”
That’s the software equivalent of nuclear war. We don’t like nuclear war! Let’s avoid that, shall we?
Range Testing
Off-by-one errors are the bane of the programmer. They’re right up there alongside the null reference exception that Tony Hoare infamously calls his “billion dollar mistake“. They’re responsible for everything from data loss to program crashes to security failures.
A wise programmer will know how to avoid off-by-one situations through the judicious use of techniques like using no raw loops. This won’t always rescue bad code, however. Proper range testing is an integral part of quality code assurance.
voyage in tech 