Another example would be any kind of control for entering data, e.g. text boxes, radio buttons, drop down lists, check boxes, and more. Let's take a text box for a product number. The valid range might be a positive number that has 6 digits. In that case you would also want to test whether you can enter less or more digits. The system should have a defined behavior. Then try entering spaces, e.g. 2 digits, then a space, then 3 more digits. Test whether you can enter nothing. Test what happens if you enter a mix of digits and characters. I'm sure you can think of more depending on the system you are working on.
One less obvious case are routes. A route allows you to enter a link that the system can interpret and translate in a specific way into a url. Routes allow certain items to be bookmarked. For example: you may want to support a url such as "http://nirvana.org/Product/246337/View" (of course your domain name would be different). The concept here is that you have the domain class name first ("Product"), the specific instance id next ("246337") and the method ("View") last. In essence a route is then: "http://nirvana.org/Product/{productId}/View". Depending on the technology you use to implement this route, somewhere you will have to extract the product id and create a url to the page that can handle this request.
The point I want to make is this: A route like this needs to be treated like a method. In essence it is similar to a method and hence there are quite a few test cases. Some examples of test you should consider:
- No product id: "http://nirvana.org/Product//View"
- Non-numeric product id: "http://nirvana.org/Product/foo/View"
- Negative product id: "http://nirvana.org/Product/-123456/View"
- Product id too short: "http://nirvana.org/Product/12345/View"
- Product id too long: "http://nirvana.org/Product/1234567/View"
