Software quality does come from testing alone. Much of quality involves good design practices. One design practice that can’t be forgotten is mistakeproofing. The japenese have a term for this - Poka-yoke.
One of the biggest mistakeproofing challenge is in creating good APIs whether for internal use or external use. We may not even be thinking we’re creating APIs, but any time you create a class or method that another developer has to use it’s an API.
Here are some examples that come to mind:
- getTaxRate(String country, String state) - it’s possible to pass these parameters in the wrong order.
- Connection dbConnection = new Connection(String longComplicatedConnectionString) - I hate this one, I often have to look at the docs to figure out how to construct the connection string.
- callRemoteMethod(String nameOfMethod, Oject params, long timeoutperiod) - many problems with this… but I’m thinking of “what if I use a timeout period that’s too short for a particular call?”
- Any time I have to call a series of methods in the *right* order.
There are endless examples of APIs that are easy to misuse. Spend some time and you’ll easily be able to come up with a few.
The next time you’re writing software on a team remember that you’re probably creating an API of some kind that has the potential for accidental misuse. Think about how the API could be misused and try to find a way to structure it so that misuse not possible or extremely difficult.