|
|
|
|
|
|
|
Enter an employee ID (negative to quit): 398405
ID: 398405 Time: 07:45:04
Enter an employee ID (negative to quit): 193847
ID: 193847 Time: 07:53:20
Enter an employee ID (negative to quit): 290387
ID: 290387 Time: 07:48:10
Enter an employee ID (negative to quit): 938473
938473 has not punched in yet.
Enter an employee ID (negative to quit): 111111
111111 has not punched in yet.
Enter an employee ID (negative to quit): -5 |
|
|
|
|
|
|
|
|
After testing this aspect of the program, we must not forget to change the value of MAX_LENGTH back to 500, recompile tclist.cpp, and relink the object code files. |
|
|
|
|
|
|
|
|
Testing and debugging an object-oriented program is largely a process of testing and debugging the C++ classes on which the program is built. The top-level driver also needs testing, but this testing is usually uncomplicatedOOD tends to result in a simple driver. |
|
|
|
|
|
|
|
|
To review how to test a C++ class, you should refer back to the Testing and Debugging section of Chapter 15. There we walked through the process of testing each member function of a class. We made the observation that you could write a separate test driver for each member function or you could write just one test driver that tests all of the member functions. The latter approach is recommended only for classes that have a few simple member functions. |
|
|
|
|
|
|
|
|
When an object-oriented program uses inheritance and composition, the order in which you test the classes is, in a sense, predetermined. If class X is derived from class Yor contains an object of class Y, you cannot test X until you have designed and implemented Y. Thus, it makes sense to test and debug the lower level class (class Y) before testing class X. This chapter's Problem-Solving Case Study demonstrated this sequence of testing. We tested the lowest level classthe Time classfirst. Next, we tested the TimeCard class, which contains a Time object. Finally, we tested the TimeCardList class, which contains an array of TimeCard objects. The general principle is that if class X is built on class Y (through inheritance or composition), the testing of X is simplified if Y is already tested and is known to behave correctly. |
|
|
|
|
|