This chapter is from the book
This chapter is from the book
This chapter is from the book
Testing Validator
The Validator application presents an interesting testing opportunity because you have several different data fields to tinker with as you check the effectiveness of the validation. You'll notice that the data types tend to progress in complexity as you move down the page. It's easy to generate a help message by either entering nothing or entering invalid data into any of the input controls, and then tabbing off of the control. Figure 7.6 shows a help message being displayed next to invalid integer data.
)
Figure 7.6 Entering invalid data and then leaving an input control results in the display of a help message next to the control.
Of course, the text "more data" doesn't exactly constitute a valid integer, which explains the help message in the figure.
Things get more interesting as you experiment with entering data into more complex types, such as the date input control. Figure 7.7 shows an invalid date message displayed in response to a nearly valid date.
)
Figure 7.7 The date input control is pretty good at detecting bad dates.
Obviously the month of January only has 31 days, so a date involving the 32nd day of the month is invalid in this example. The Validator application catches the input error and displays a help message.
Although date validation is handy, the most intriguing part of the Validator application is the lookup of ZIP codes, which takes place when you enter a ZIP code into the ZIP code input control and then leave the control. Figure 7.8 shows the animated "loading" image displayed as the ZIP code Ajax request is being carried out.
)
Figure 7.8 The "loading" image is displayed in lieu of a help message to let the user know that the ZIP code is being looked up.
Yeah, I know, I couldn't resist using the most popular ZIP code on Earth to test out the application. If the ZIP code data is successfully retrieved via the Ajax request, the resulting city and state are displayed in place of the "loading" image, as shown in Figure 7.9.
)
Figure 7.9 A successful ZIP code Ajax request results in the display of the associated city and state next to the input control.
Success is great, but what happens when a ZIP code isn't found? If you recall in the code for the application, a help message is displayed to indicate this. Figure 7.10 shows the help message displayed in response to a ZIP code that isn't associated with a real city and state.
)
Figure 7.10 A ZIP code with no real-world city and state results in a help message indicating that the ZIP code couldn't be found.
It's important to note that a ZIP code that isn't found isn't necessarily invalid in a strict data entry sense. Yes, it isn't in use in the real world, which is a problem if you're entering a shipping address, for example, but that doesn't mean it won't be real someday. ZIP codes are not etched in stone, and in fact they are created anew on a fairly regular basis in fast-growing areas. That's the beauty of relying on a third-party service to handle the ZIP code lookup—it is responsible for keeping its ZIP code database up to date, not you.
Regardless of how you handle the issue of a ZIP code not being used in the real world, hopefully you can see how the Validator application lays some important groundwork in data validation that you can reuse and repurpose in all kinds of useful ways.