Testing is a dynamic approach to verification in which software is executed with test data to assess the presence of required features. The inferences involved in this process are complex. Testing employs analysis to determine software characteristics. The software characteristics are then used to evaluate whether features are present or missing. What constitutes a "unit" has been left imprecise. It may be as little as a single statement or as much as a set of coupled modules. The essential characteristic of a unit is that it can meaningfully be treated as a whole.

What is a unit test?
The primary objective of the unit test is to convert the completed design into source and executable code. When prototypes exist, they should be upgraded into the actual software, to the extent feasible. Unit test is performed to verify that each CSU performs as intended. Unit tests is documented and run informally. They are conducted by Software Engineering (the programmers).

Refer back to the Software Unit Testing Kernel shown in Example Software Development Process linked below.

The Example Software Development Process shown in the link above is based on a predefined repository of process "kernels" from which the testing, verification & validation life cycle for a given project can be defined. A "kernel" is defined for each function such as Requirements Analysis, Document Review, Code Analysis, Unit Testing, etc. Each "kernel" contains entry and exit criteria, inputs and outputs, activities, process controls, and metrics for a given activity. These kernels are then mapped to the development model (Waterfall, Cyclic, etc.) determined by the needs of the project.

The kernel is a concept developed by Lillian K. Zelinski at Science Applications International Corporation (SAIC) in Arlington, VA and presented in her paper "Constructing Independent Verification and Validation Life Cycles Using Process Kernels", at the 10^th Annual IEEE COMPASS Conference, June 26-30 1995, Gaithersburg, MD USA.

The Software Unit Testing Kernel is a modular, reusable, self-contained building block defining inputs, entry criteria, activities, exit criteria, outputs, process controls, and metrics. As an example, the Software Unit Testing kernel is shown in Figure 2.

The purpose of the Software Unit Test kernel is to test each component and remove all errors within that component. Testing is first focused on the smaller building blocks of the program rather than initially testing the program as a whole.

1. All inputs and outputs of the component should be tested.
2. Unit test starts after rework is done from the code inspection.
3. Unit test is the only place that all error paths in a component are tested.
4. Coverage is to be 100% of every new and modified line of code of that component.

The Entry Criteria describes the circumstances under which a kernel becomes activated. All entry criteria should be fulfilled before commencing with the activities defined for the kernel. If some entry criteria cannot be fulfilled, a work-around may be necessary. All such deviations from what is prescribed in the kernel must be performed to maximize risk reduction and minimize adverse impacts to quality. All deviations must also be documented appropriately.

Unit Test Entry Criteria When a unit has been coded from its module specification and all errors detectable by a compiler have been removed then the module is ready for unit test.

1. Source and executable code.
2. Unit test plans.
3. Unit test cases.

The Inputs identify the data items that are required to support the activities of the kernel. For the most part, these are outputs of other kernels or products of the software development process such as test plans or design documents.

1. Units under test.
2. Unit test planning data, drivers, and problem logs.
3. SEE/STE.
4. Software project planning data.
5. Engineering change control data.

Activities describe a minimum set of actions that will produce the output items and meet the exit criteria objectives. For each related set of actions, step by step procedures are available to support consistency among analysts, adherence to proven practices, and training. If all activities cannot be performed, management steps to reduce risk should be taken, they should be noted in the outputs products (such as the Requirements Analysis Report), and the kernel closed.

Exit Criteria identify the circumstances under which the kernel is completed or de-activated. It includes delivery or presentation of results, and passing of information to other kernels (such as the passing of comments to the Configuration Management kernel for tracking).

Unit Test Exit Criteria. For each new or changed module, all of the test cases for unit test have been successfully executed. Defects found have been fixed or an action plan is in place to solve them. All fixes have been re-tested. Updates to the Engineering build kernel.

Outputs identify products of the kernel activities and are either deliverable items or are required to support other kernels.

Process Controls define quality assurance activities that are performed for the kernel. These are detailed in the Project Management and Quality Assurance kernels and are documented in the Project Management Plan.

Metrics are the categories of measures collected and maintained for each kernel. The details of each metric are specific to each kernel and are defined in a Metrics Program Plan. The metrics allow the monitoring of trends and identification of problem areas.

Emphasis of Unit Test. Unit testing is one of the most critical testing phases. If this phase is done correctly, the remaining test phases will be easier. This is the lowest level testing applied to each module, routine or subroutine in the software. Generally, each unit has a test driver and several test cases associated with it. This testing type's sole purpose is to identify as many internal logic errors as possible. Therefore the Software Engineer needs to perform the following activities:

1. Verifying
   1. The unit against its design. Unit test needs to ensure that the unit does what it was designed to do. This is based on software engineering principles that during peer reviews at the unit design phase, the design was verified to be "good".
   2. Unit requirements. Verify that all software requirements are correctly implemented.
   3. Unit inputs & outputs. Combinations of good & bad data input and output needs to be exercised. Equivalence class partitioning is important at this stage to limit the amount of test cases that need to be developed for input and output testing.
   4. Error conditions. This may be covered during coverage testing but is called out separately since error conditions need to be carefully evaluated and tested.
2. Addressing statement coverage. Unit test is the only phase of test
where it is possible to come close to executing all possible combinations of data.
3. Meeting quality guidelines. Unit testing should include quality checks, where the code is examined using general criterion and standards to evaluate its good and bad characteristics.
4. Managing. Unit testing is a way of managing the combinations of testing since attention is focused initially on smaller units.
5. Debugging. Unit testing eases the task of debugging since, when a defect is found, it is known to exist in a particular unit.