Testing the program was achieved by running each program with different values. The titles for each test are simply the name of the output redirected to file. These output testfiles are included on the disks. It should be noted that testfiles do not show the user input. User input is shown in this section through use of italics.
This first test tries to run the program without command line arguments. It was expected that the ‘incorrect arguments’ message would be shown and the program would terminate. As is shown below, this happened.
c:/>testdial incorrect number of arguments usage: testdial <minutes increment>
This test runs the testdial program with ‘ordinary’ data. It was expected that the program would run to completion.
c:/>testdial 15 Lez Bullwer & Mingguang Lui bedtime = 23:00 alarm set for 07:00 snooze set for 07:30 minutes increment: 15 23:15 23:30 23:45 00:00 00:15 etc. 06:00 06:15 06:30 06:45 07:00 Brrrrrrrrrrrrrrrrrrrrrrrr 07:15 07:30 Brrrrrrrrrrrr
This test attempts to put in a large incremental value of one hour. Initial expectation was that this would run correctly.
c:/>testdial 60 Lez Bullwer & Mingguang Lui bedtime = 23:00 alarm set for 07:00 snooze set for 07:30 minutes increment: 60 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 Brrrrrrrrrrrrrrrrrrrrrrrr 08:00 09:00 10:00 12:00 ... continues Had to be manually terminated
As shown above, this test failed and the program had to be manually terminated. The infinite looping occurred because 07:30 was never ‘hit’ exactly. Tests were also performed with the increment as 45 and 140, both of which produced similar results.
This test had the increment command line argument input as a decimal number. It was expected that this would loop endlessly since only the first character of the argument would be used, i.e. the zero.
c:/>testdial 0.5 Lez Bullwer & Mingguang Lui bedtime = 23:00 alarm set for 07:00 snooze set for 07:30 minutes increment: 0 23:00 23:00 23:00 23:00 ... continues Had to be manually terminated
As shown above this test had to be manually terminated. With the increment set at zero the dials never advance and consequently can never ‘hit’ 07:00 (or 07:30).
These tests use a negative number and a large number for the increment. It was expected that each of these tests would throw the ‘invalid argument’ message since both negative numbers and maximum value numbers are tested for in the program.
c:/>testdial -15 invalid argument - must be positive and < 1440 c:/>testdial 1441 invalid argument - must be positive and < 1440
Again, as with the ‘incorrect arguments’ message this error terminates the program.
The same set of values used for testing testdial.exe are used again for testing testclk.exe.
No command line arguments. As with testdial, this throws an error message and terminates the program.
c:/>testclk incorrect number of arguments usage: testclk <minutes increment>
These tests use a value of 15, which worked with testdial, and a value of 60, which failed with testdial.
c:/>testclk 15 Lez Bullwer & Mingguang Liu bedtime = 23:00 alarm set for 07:00 snooze set for 07:30 minutes increment: 15 time = 23:15 time = 23:30 time = 23:45 time = 00:00 time = 00:15 time = 00:30 etc. time = 06:30 time = 06:45 time = 07:00 Brrrrrrrrrrrr time = 07:15 time = 07:30 Brrrrrrrrrrrrrrrrrrrrrrrr |
c:/>testclk 60 Lez Bullwer & Mingguang Liu bedtime = 23:00 alarm set for 07:00 snooze set for 07:30 minutes increment: 60 time = 00:00 time = 01:00 time = 02:00 time = 03:00 time = 04:00 time = 05:00 time = 06:00 time = 07:00 Brrrrrrrrrrrr time = 08:00 Brrrrrrrrrrrrrrrrrrrrrrrr |
This test using 140 for increment failed with testdial program. However, it is expected that this value will succeed with testclk.
c:/>testclk 140 Lez Bullwer & Mingguang Liu bedtime = 23:00 alarm set for 07:00 snooze set for 07:30 minutes increment: 140 time = 01:20 time = 03:40 time = 06:00 time = 08:20 Brrrrrrrrrrrr time = 10:40 time = 13:00 time = 15:20 time = 17:40 time = 20:00 time = 22:20 time = 00:40 time = 03:00 time = 05:20 time = 07:40 Brrrrrrrrrrrrrrrrrrrrrrrr
It should be noted that although the alarms goes off as near after 07:00 and 07:30 as they can there is a whole day in-between!
c7.txt used a decimal number for the increment. Like testdial, testclk took an increment value of zero and so the clock never advanced. The program had to be manually terminated.
c:/>testclk 0.5 Lez Bullwer & Mingguang Lui bedtime = 23:00 alarm set for 07:00 snooze set for 07:30 minutes increment: 0 23:00 23:00 23:00 23:00 ... continues Had to be manually terminated
c8.txt and c9.txt used values which were ‘out of bounds’ (-15 and 1441 respectively). These each produced the ‘invalid argument - must be positive and < 1440’ message and terminated the program.
This extra test for testclk included a non-numeric increment value.
c:/>testclk a Lez Bullwer & Mingguang Lui bedtime = 23:00 alarm set for 07:00 snooze set for 07:30 minutes increment: 0 23:00 23:00 23:00 23:00 ... continues Had to be manually terminated
As shown above, the program took the value ‘a’ as a zero and so the clock never advances.
This first test used ‘ordinary’ data to check the program did add up correctly. Three measurements are input. The intermediate result is shown in yards, feet and inches with the final result converted to metres.
Imperial addition & conversion to Metric ---------------------------------------- Enter length in feet and inches (e.g. 2 6): *** Positive values only *** Length : 1 10 Length (non-numeric to finish): 2 6 1 yds 1 ft 4 ins Length (non-numeric to finish): 0 8 1 yds 2 ft 0 ins Length (non-numeric to finish): 1 11 2 yds 0 ft 11 ins Length (non-numeric to finish): q 2 yds 0 ft 11 ins in metres: 2.1082
This test was to input values in feet and inches which are larger than the ‘dials’ that contain them:
Imperial addition & conversion to Metric ---------------------------------------- Enter length in feet and inches (e.g. 2 6): *** Positive values only *** Length : 15 30 Length (non-numeric to finish): q 5 yds 2 ft 6 ins in metres: 5.334
As shown, the program correctly converted the over-valued feet and inches input to yards, feet and inches.
These two tests use characters in the input. Con3.txt entered an ‘x’ for the first value which caused the program to terminate before performing any calculations. Con4.txt used a decimal number for input, but because the input values must be integers, anything else is rejected and so the program terminates. The program also exits if a negative value is included as either the feet or inches value.
Imperial addition & conversion to Metric ---------------------------------------- Enter length in feet and inches (e.g. 2 6): *** Positive values only *** Length : x Exiting Imperial addition & conversion to Metric ---------------------------------------- Enter length in feet and inches (e.g. 2 6): *** Positive values only *** Length : 0.5 1 Exiting
This test shows what is output when an inch value is entered as a decimal value.
Imperial addition & conversion to Metric ---------------------------------------- Enter length in feet and inches (e.g. 2 6): *** Positive values only *** Length : 1 0.5 Length (non-numeric to finish): (nothing input here) 0 yds 1 ft 0 ins in metres: 0.3048
Although this appears to accept the data entered, it only reads the zero as the first inch value. The period ‘.’ is held in a buffer and is then taken as the second length value. But because it is a non-numeric value, it terminates the program.
This test includes a very large input value, which takes the yard value ‘over the top’.
Imperial addition & conversion to Metric ---------------------------------------- Enter length in feet and inches (e.g. 2 6): *** Positive values only *** Length : 300 0 Length (non-numeric to finish): 0 0 over 100 yards - restarting count 0 yds 0 ft 0 ins Length (non-numeric to finish): 1 1 0 yds 1 ft 1 ins Length (non-numeric to finish): q 0 yds 1 ft 1 ins in metres: 0.3302
This first test uses ‘ordinary’ data. This program calculates the distance travelled using the speed and time provided by the user input. The output shows the start point, end point and total distance travelled in imperial and metric units.
Enter start position in inches ( 0-11 ): 0 How far does the worm travel per hour? (in inches): 10 How many hours does the worm travel?: 3 Worm travelled from: 0 yds 0 ft 0 ins Worm travelled to: 0 yds 2 ft 6 ins Distance in inches: 30 In metres this is: 0.762
Limits have been built in to the program (see worm.cpp page 23). This test shows the result of inputting the highest permitted values.
Enter start position in inches ( 0-11 ): 11 How far does the worm travel per hour? (in inches): 50 How many hours does the worm travel?: 24 Worm travelled from: 0 yds 0 ft 11 ins Worm travelled to: 33 yds 1 ft 11 ins Distance in inches: 1200 In metres this is: 30.7594 ... and the worm was very tired!!!!!!
This also shows the extra message for a resulting distance of greater than 2 metres.
This test incorporates testing of input for negative, decimal and character values. These values should give an error message and allow the user to input again.
Enter start position in inches ( 0-11 ): -9 Incorrect input. Try again Enter start position in inches ( 0-11 ): 9 How far does the worm travel per hour? (in inches): a Incorrect input. Try again How far does the worm travel per hour? (in inches): 3 How many hours does the worm travel?: 0.5 Incorrect input. Try again How many hours does the worm travel?: 6 Worm travelled from: 0 yds 0 ft 9 ins Worm travelled to: 0 yds 2 ft 3 ins Distance in inches: 18 In metres this is: 0.6858
This test is to show the extra error messages output when the values for speed and time are too large.
Enter start position in inches ( 0-11 ): 0 How far does the worm travel per hour? (in inches): 60 A worm can't go that fast!! Incorrect input. Try again How far does the worm travel per hour? (in inches): 6 How many hours does the worm travel?: 30 A worm can't crawl for that long!! Incorrect input. Try again How many hours does the worm travel?: 3 Worm travelled from: 0 yds 0 ft 0 ins Worm travelled to: 0 yds 1 ft 6 ins Distance in inches: 18 In metres this is: 0.4572
As with the testdial and testclk programs, elecmetr.exe takes command line arguments. This first test tries to run the program without arguments.
c:/>elecmetr incorrect number of arguments current reading required (4 digits) as follows: usage: elecmetr <thousands hundreds tens units> e.g. if current reading = 1234 then enter: elecmetr 1 2 3 4
el2.txt uses realistic data to test the program. The command line arguments initialise the reading and this is used in the output as ‘previous reading’.
c:/>elecmetr 0 0 0 0
no. of units used per day? (< 100) : 10
no. of days to run? (< 100) : 20
Previous reading: 0000
Current reading: 0200
Units used: 200
Cost per unit: £ 0.08
=======
Total cost of units used: £ 16.00
The cost per unit is fixed in the elecmetr.cpp file.
This test is to show the meter dials rolling over. An initially high value is input, with other data entries forcing the dials to ‘turn over’.
c:/>elecmetr 9 9 9 9
no. of units used per day? (< 100) : 10
no. of days to run? (< 100) : 20
Previous reading: 9999
Current reading: 0199
Units used: 200
Cost per unit: £ 0.08
=======
Total cost of units used: £ 16.00
As can be seen, the roll-over takes place and the total cost of units used reflects this. The calculation for producing ‘units used’ takes into consideration which reading is the larger. If the current reading is smaller than the previous reading then the dials must have rolled-over and so the calculation is adjusted accordingly.
el4.txt was to test the program with values which are larger than the acceptable values. An error message is shown and the user is prompted for the input again.
c:/>elecmetr 9 9 9 9
no. of units used per day? (< 100) : 150
Incorrect input. Try again
no. of units used per day? (< 100) : 99
no. of days to run? (< 100) : 150
Incorrect input. Try again
no. of days to run? (< 100) : 99
Previous reading: 9999
Current reading: 9800
Units used: 9801
Cost per unit: £ 0.08
=======
Total cost of units used: £784.08
el5.txt is similar to el4.txt. This test is for spurious input values of characters and negative numbers. As shown below, both of these inputs produce an error message and the user is given the opportunity to re-enter a value.
c:/>elecmetr 1 2 3 4
no. of units used per day? (< 100) : q
Incorrect input. Try again
no. of units used per day? (< 100) : 10
no. of days to run? (< 100) : -1
Incorrect input. Try again
no. of days to run? (< 100) : 10
Previous reading: 1234
Current reading: 1334
Units used: 100
Cost per unit: £ 0.08
=======
Total cost of units used: £ 8.00
These three tests all produce the ‘incorrect number of arguments’ message, with the program terminating. El6.txt shows mistyped command line arguments. El7.txt shows the result of using negative values as the initial meter reading entry. This is, obviously, not allowed. El8.txt shows the result of including a character instead of a number in the command line arguments.
c:/>elecmetr 0 00 0 incorrect number of arguments current reading required (4 digits) as follows: usage: elecmetr <thousands hundreds tens units> e.g. if current reading = 1234 then enter: elecmetr 1 2 3 4 c:/>elecmetr –1 1 1 1 incorrect number of arguments current reading required (4 digits) as follows: usage: elecmetr <thousands hundreds tens units> e.g. if current reading = 1234 then enter: elecmetr 1 2 3 4 c:/>elecmetr 1 1 1 q incorrect number of arguments current reading required (4 digits) as follows: usage: elecmetr <thousands hundreds tens units> e.g. if current reading = 1234 then enter: elecmetr 1 2 3 4