The usual discussions of testing distinguish between unit tests and integration tests, between verification tests and validation tests, between white box and black box testing. The discussions also distinguish the strategies of top down and bottom up testing.
Unit testing is the testing of a code entity in isolation; for example, a single method of a class or a single, free-standing procedure. When the functionality of a larger entity depends on the working of two or more such units, the testing of the combination is called an integration test. This covers the very real possibility that two units can function quite correctly in isolation but fail in combination; for example, due to a flaw in the exchange of information and/or services between them. An entity is tested as a black box if the tests are merely designed to observe that representative input cases produce the expected results. A white box test, on the other hand, ``looks inside'' the entity. Such tests are design to exercise the various control paths and computations of the code itself. (Clearly, such tests have to be planned much later in the development process than would be true for black box tests, since the actual implementation code must be known.) All testing described above verifies that the code does what it was written to do. This may not be what the requirements demanded. It is sometimes easy to lose track of the original demands when one is several months along in the implementation. Thus a validation test is one that takes a finished system and ensures that it will satisfy the requirements.
The strategies of testing, top down or bottom up, have the same meaning as in design. In top down testing, the entire system in simple outline is written, with most or all subsystems represented by stubs. Little by little, functionality is added to the system by replacing stubs with functioning code entities (which, for a while, may have sub-entity stubs). Little by little the system is fleshed out from the large to the small. In bottom up testing, the fundamental entities of infrastructure are written first and tested in scaffolding code, which serves as temporary system glue. The system is built from the small to the large as more and more entities are integrated together through the inplementation of the final system code. These two strategies are rarely found in pure form. Parts of the system may be built from the bottom up and others from the top down.
Another term is often seen in discussions: big bang testing.
Essentially this means that no testing is done on individual entities,
only on the system as a whole (or perhaps, on major subsystems).
This will be considered a bad thing in this course.