Customer requirements typically specify some combination of function, performance, data, and workflow.  A general template for this can be illustrated as:

The customer typically thinks in terms of the user interface, clicking on a button that does something, and having the user interface change as a result.  The customer also specifies the data, from the presentation level perspective.

The program implements this workflow by decomposing the workflow into a set of processes (typically determined by the customer as well, because the customer wants the processes in the workflow to remain familiar).  Each process is then decomposed into a set of functions, again, often functions familiar to the customer.  Automated workflows (in which the entire workflow is a black box to the customer) are less coupled to the customer's concept.

Unit testing of the customer requirements therefore consists several things, each at a different quantization.  From bottom up:

• Testing each function

• Testing each process

• Testing the workflow

It should be understood that unit testing on the function level is not sufficient.  The process level integrates the functions, just as the workflow level integrates the processes.  Just because the functions are working doesn't mean that the programmer put together the processes correctly, and the same for a workflow built out of the processes.  Keep in mind that the term "function" relates to the customer's concept and does not necessarily map one for one to class methods.