RSS
| << 9.3.7- Use a Variable Naming Convention (Consistently!) | Chapter9 | 9.4.0- Debugging ASP Script >> |
Try to Break your Code
When you test your code (you DO test it, don't you?) one thing to do is to supply your programs with rogue values (massive numbers, or letters instead of numbers and such like) to see how your program reacts. You may not have intended your program to be abused in such a way but, when it's out in the real world, these are exactly the type of values that may get put in to your program. If your program breaks under this sort of stress, then you'll have many perplexed and unhappy users.
A good strategy for doing this is to break down all the possible values into three types:
- Expected values – these are values in the range that you ask for. If you asked for numbers between 1 and 10, these would be 2 through to 9.
- Boundary Condition values – these are the values that lie at the boundaries of our range. If you asked for numbers between 1 and 10, then did you actually mean to include these values or not? Does your program deal with them correctly?
- Out-of-Bounds values – these are the values that fall anywhere outside the range. In our example, -5, 0 and 999 would all be out of bounds values. But, it doesn't stop there; this could equally apply to values of an unexpected type, such as a letter or date. For instance were you expecting one of these values: 0, -1, 0.9, -1E5, 10.1, 5.5, "dog", #5/9/58#, "true", "false", (empty), 4+4, 5/0, 9.9, 9.99, 9.999, 003, "three"? Will your program cope with all of these types?
Testing your code with the kind of values you'd expect your user to supply is an absolute must. If you ask a user to supply a number between 1 and 10, you must test your program using each and every number between one and ten. And while, realistically, you couldn't test every possible out of bounds value that could be input, you do need to hypothesize a large possible range of values and different types. If your program doesn't break when the user inputs 11, that's all very well and good, but does it still work when the user enters "three", which would be a perfectly "correct" answer to the question in some user's minds?
Creating Error Traps
In my Computer Science class it was a ritual routine that once we'd finished a large program, we'd pass it around other members of the class to see if they could break it. If someone did manage to break it they'd display the bug with great merriment to the rest of the class (OK, we were spotty teenagers then). On a more serious note, this is pretty much how everybody tests code. Microsoft, for instance has a team of people coding applications by day and then another team testing that same code at night.
In our case though, unlike Microsoft, a few simple lines of easily modifiable code usually made our little applications relatively weatherproof. Let's look at a trivial program that takes a number between 1 and 5 from the user and multiplies it by ten. The purpose of this exercise isn't the calculation, but actually ensuring we get what we want from the user.
Try It Out – Expecting the Unexpected
1. Open your trusty web page editor and type in the following:
<HTML>
<HEAD>
<TITLE>Userproof Page</TITLE>
</HEAD>
<BODY>
<FORM NAME="Form1" ACTION="check.asp" METHOD="POST">
Please enter a whole number from one to five (1-5)<BR>
<INPUT TYPE=TEXT NAME=TextBox1>
<BR>
<BR>
<INPUT TYPE=SUBMIT>
</FORM>
</BODY>
</HTML>
2. Save it as enter.asp, in the usual folder. Close it and then type in the following code:
<HTML>
<HEAD>
<TITLE>Check Page</TITLE>
</HEAD>
<BODY>
<% varTest = Request.Form("TextBox1")
If IsNumeric(varTest) = False Then
Response.Write "No Letters<BR>"
Server.Transfer "enter.asp"
End If
If varTest<1 Then
Response.Write "Too Small<BR>"
Server.Transfer "enter.asp"
End If
If varTest>5 Then
Response.Write "Too Large<BR>"
Server.Transfer "enter.asp"
End If
If CDbl(varTest) <> CInt(VarTest)then
Response.Write "No decimals<BR>"
Server.Transfer "enter.asp"
End If
varTest = varTest * 10
Response.Write "<BR>Your lucky number is " & varTest
%>
</BODY>
</HTML>
3. Save this as check.asp and close your editor.
4. Open up your browser and run enter.asp.
5. Enter a letter and submit it:
|
|
6. Try various other erroneous values. You will find that the only way you can get to this screen is by entering the numbers 1,2 3,4 or 5. For example we've entered 3:
|
|
How It Works
We read the textbox on the form into a variable.
<% varTest = Request.Form("TextBox1")
As yet we don't know what type the subtype of variable is so we prefix it with var (short for variant). First, we test to see if a letter has been input:
If IsNumeric(varTest) = False Then
We use the VBScript function IsNumeric, which returns False if the variant is anything other than a number. Then we return a suitable message and transfer back to the first page and await another response:
Response.Write "No Letters<BR>"
Server.Transfer "enter.asp"
Then, in turn, we check to see if the variant is too large, too small or a decimal. If it fails any of these tests, we output a suitable message and return to the enter.asp page. Otherwise we multiply the variant by 10 and output the result:
varTest = varTest * 10
Response.Write "<BR>Your lucky number is " & varTest
The idea is that this code is reusable, as you only have to change the first variable assignation to whichever part of your form needs testing, and alter the values in the tests:
varTest = Request.Form("TextBox1")
| << 9.3.7- Use a Variable Naming Convention (Consistently!) | Chapter9 | 9.4.0- Debugging ASP Script >> |
