Location: [CPSC 333] [Lab Exercise] [Previous Exercise] [Next Exercise] Exercise #10
The following exercise will be taken up in the first labs during the week of April 7-10. If at all possible, you should try to solve these problems ahead of time, so that you can compare your own solutions to the ones presented during labs, or have questions ready to ask in case you had trouble solving them.
This is based on material presented in class on April 2-4, 1997.
List at least one of the orders in which subsystems might be formed and tested, if system integration and integration testing was being performed for the system corresponding to the first version of the Student Information System, whose structure chart was developed as an example for structured design,
Briefly describe the additional testing code you'd need to write in order to test each of the subsystems considered above.
The directory
~eberly/CPSC333/Lab10
contains a source code file, silly_palindrome.cpp, along with a program silly that was compiled from it using CC or g++.
The source code includes a main module and two functions. Each of the functions uses a nontrivial ``assumption,'' which is easily checked using a simple boolean expression that can be written in C++.
Use assert to add checks for these assumptions. If you have time, play with the source code, by introducing errors so that the functions can be called when the assumptions aren't satisfied, compile the resulting program, and run it on examples in order to see what happens when assert finds a problem.
If you have even more time, write code for simple stubs replacing the two function, and drivers that could be used to call them, so that you could perform unit testing on each of the functions in the modules, as well as integration testing on the entire system.
This is clearly not a very sensible program; it's only been designed to be used as an exercise for testing!
The above directory also contains a source file, sillier_palindrome.cpp, for yet another version of this program, which hasn't yet been compiled.
This version is even ``sillier,'' but more valuable for a testing exercise, because it has a number of errors seeded into it. You will be able to find evidence of some of these errors by compiling the program (or, trying to) and (eventually) running it on randomly chosen examples; if you use the assert package to enable checking of function's assumptions then, this time, you'll also be able to confirm that the functions are being called when the assumptions are invalid.
In order to test ``sillier_palindrome.cpp,'' add assert statements for function assumptions. Compile the program using the command
g++ -g sillier_palindrome.cpp
This will produce a version of the executable program that can be used with the debugger, gdb.
You'll discover that you'll need to make a change to the source code, in order to be able to compile the program at all. Make this change and try again.
Once you've managed to compile the program, run it on a few examples. You should (unfortunately) find that assert complains, and causes a core file to be generated, if you've only made the changes needed to allow the program to compile, and if you've used assert correctly.
Now, read the man page for the debugger gdb, and note how you can call this debugger in order to apply it to your program. Note as well how you can cause the program to run, how you can cause it to run a single step at a time, how you can set ``breakpoints'' so that execution will pause when functions are called, how you can continue execution after that, and how you can display the source being executed, and print and set the values of variables during execution. (If all else fails, note that you can type ``help'' when the gdb is running in order to obtain some useful information; you can also type ``help step'' for more information about the ``step'' function, etc.)
Try to review the source code, use methods for testing discussed in the course, and use the debugger, to remove the errors that have been seeded into ``sillier_palindrome.cpp.''
Once you've done this, make another change, or recompile with a flag set, in order to produce a ``production'' version of the program that doesn't include the assertion checking - but do this without removing the assert statements that you added to the program (so that they'll still be there, if you need them for testing again later on).
Finally, note that since I've supplied you with a ``correct'' version of the program already, you can find another Unix utility that you should know about already, to find where the seeded errors are. If you aren't sure how to do this, read the man page for diff.
Location: [CPSC333] [Lab Exercises] [Previous Exercise] [Next Exercise] [Exercise #10]