1.2. Unit Testing

1.2. Unit Testing
	1. Unit Testing

By testing modules in isolation from the rest of the system

Easier to design and run extensive tests
Much easier to debug any failures
Errors caught much earlier

Main challenge is how to test in isolation

Scaffolding

To do Unit tests, we have to provide replacements for parts of the program that we will omit from the test.

Scaffolding is any code that we write, not as part of the application, but simply to support the process of Unit and Integration testing.
Scaffolding comes in two forms
- Drivers
- Stubs

Drivers

A driver is test scaffolding that calls the module being tested.

Often just a simple main program that reads values, uses them to construct ADT values, apply ADT operations and print the results

Example: A Test Driver for Time

We can run this manually:

andromeda> ./testTime
Default: 00:00:00
01:00:10 14:00:00
01:00:10 14:00:00
Gets: 1 0 10 14 0 0
add: 15:00:10
difference: 00:00:00
noLaterThan: 1 equalTo 0
23:59:59 23:59:59
23:59:59 23:59:59
Gets: 23 59 59 23 59 59
add: 47:59:58
difference: 00:00:00
noLaterThan: 1 equalTo 1
andromeda>

(Note: in order to end the execution of this program, we would need type the "end of input" character, Ctrl-Z in Windows, Ctrl-D in Unix & Linux.)

Using the Test Driver

Or we could automate by recording a set of test inputs

01:00:10 14:00:00
14:00:00 01:00:10 
00:00:00 23:59:59
00:00:01 23:59:59

and a set of expected outputs:

Default: 00:00:00
01:00:10 14:00:00
Gets: 1 0 10 14 0 0
add: 15:00:10
difference: 00:00:00
noLaterThan: 1 equalTo 0
14:00:00 01:00:10
Gets: 14 0 0 1 0 10
add: 15:00:10
difference: 00:00:00
noLaterThan: 0 equalTo 0
00:00:00 23:59:59
Gets: 0 0 0 23 59 59
add: 23:59:59
difference: 00:00:00
noLaterThan: 1 equalTo 0
00:00:01 23:59:59
Gets: 0 0 1 23 59 59
add: 24:00:00
difference: 00:00:00
noLaterThan: 1 equalTo 0

and then comparing our output to the expected:

./testTime < testTime0.dat > testTime0.out
diff testTime0.expected testTime0.out

Stubs

A stub is test scaffolding written to replace types nad function used by the module under test.

Suppose we wanted to test BidCollection but had not yet implemented Bid
Could try to write a simple stub for Bid:
```
    typedef std::string Bid;  
```
- Unfortunately, this would not compile because of the calls to Bid member functions in addInTimeOrder.
Would need something a little more elaborate
But that would be enough to let us test that BidCollection worked, in particular that it kept elements in sorted order, provided access to them, and could be printed.


1.1. Types of Testing		1.3. Integration Testing