Usually, when working in an application (at any level, design, implementation…) we focus on what it should do, and on the path we set up for the user to accomplish a task. We don’t think too much about errors, other than (maybe) catching them all and printing a cryptic, generic message to the end user.No wonder they come back with very detailed issues such as “it doesn’t work“… but I digress.
The current trend is paying little attention to errors. In Java, that means turning exceptions in RuntimeExceptions. It leads to much simpler code… doesn’t it?
There are some places where you just can’t forget about errors. That’s the user interface. There is no higher level layer which can manage the errors. They are spit in the user’s face. And you don’t want to do that (well, at least not to too many users).And errors are not the only things your applications needs to be prepared to handle. What about strange values? I mean things like text that is too long (will it screw up your HTML layout?), HTML code in a supposedly text-only field (is it escaped? or will it be rendered?)… I guess that you get the idea.
But real data might not be real enough. How many samples are you using? How many users have entered them? Experience tells us that different people type things in different ways, so you should have enough people giving you enough data for your tests.
And, on top of that, add your experience as a developer to test for the classical error conditions.
As a starting point… what about:
- Zero length strings (they are sometimes converted to null)
- Really long strings (they can break your layout)
- HTML in text strings (they can truncate the displayed data)
- International chars (they can show up as question marks if not encoded properly)
- Don’t use GUI prompts on a server-side process (an obvious one, but I’ve actually seen a daemon process asking the user to press OK on a dialog)
This is a quick post, so I’l be happy if you add some more suggestions in your comments.
I’m waiting… 😉