Document your plans for testing the components of your product for Componenten 2, and how you intend to integrate them.
For each component, specificy the software facilities (drivers, stubs, generators, comparators, files, etc.) needed to perform rigorous, thorough, automatic, and reproduceable unit tests. Automatic here concerns both performing the test runs and checking the outcomes. Also describe how these facilities are to be used in concreto to perform the required tests. (Consider the use of the unit testing framework in the standard Python Library.)
Strive for generic facilities, which can be used for more than one component (in such cases, do not duplicate specifications, but refer to the separately specified common facilities).
For each component, specify an adequate set of test cases.
Motivate every test case, e.g. as a boundary case, related to some equivalence class, in terms of coverage, etc. Relate test cases explicitly to component requirements and specifications as presented in the Requirements Document and the Architecture Document (black box), or to implementation details (glass box) in the Detailed Design. Identify each test case through a (unique) identifier.
Note that this does NOT imply that the actual input and output data for the test cases has to be generated and included in the UTP. Each test case specification must
Based on the test case specifications, it must be possible to supply the missing details without extra mental effort, and it must also be possible to estimate the cost (effort) need to supply these details.
The following items do NOT belong in this assignment:
However, for the course Componenten 2 it is important to show that certain components can be replaced by each other. This could well be done by subjecting those components to the same unit test and reporting about the results.
Describe how stepwise integration (assembling the system from the components) will be done, including a systematic verfication of whether the components from the Architectural Design interface and cooperate well.
The big-bang approach (put everything together in one step) is NOT an option. There must be at least one intermediate step: a partial system, consisting of more than one component, and fewer than all components).
It is very well possible (and recommended) that the ITP refers back to the UTP for certain common facilities.