A Unit is not ready for formal unit testing until there is a formal unit test plan document that should contain:

Identification of the unit, its programmer, the module of which it is a part, the date submitted for formal unit testing, version number, and any other information required to properly track it.

A brief statement of its purpose and function and references to the unit's formal requirements specification

A brief description of how it works and references to the detailed documentation

Assumptions and prerequisites for testing. For example, program version, data base, hardware configuration, special test gear, and so on.

The total number of unit tests to be run. Identification of the unit tests required to provide coverage. Number of tests attempted, percentage passed, list of bugs or deficiencies found, percentage of coverage achieved this far.

Test sheet for each test with the following information:

Test number and type (path test, syntax test, state test, functional test, and so on)

Date attempted, outcome (pass/fail), rework or corrective action with dates, reschedule date

Data-base prerequisites

Initialization method or initial conditions assumed

Inputs

Outcomes

Method of verifying outcomes

Instrumentation plan

Context of runs

Test plan should be reviews prior to execution. Three different reviews with three different objectives:

By the programmer

By the programmer's supervisor or peers (the most important review)

By quality assurance (a formality if #2 is fully done or redone)