GENERIC

UNIT TEST STANDARD

The Generic UWF Maintenance Process (GUMP) 1994, 1995, 1996, 2005 The University of West Florida. All rights reserved.

Permission is granted to reproduce and adapt this document provided credit is given to the University of West Florida. This documentation is provided "as is" and no warranty of fitness for any particular purpose is made or implied.

ABSTRACT

This document is the Unit Test Standard document for the generic maintenance process for the University of West Florida.

TABLE OF CONTENTS

ABSTRACT
1.0 UNIT TEST STANDARDS
1.1 INTRODUCTION AND DEFINITIONS
1.1.1 Definition of a Unit in C/C++
1.1.2 Definition of a Unit in Java
1.2 PERSONNEL
1.3 IMPLEMENTATION WALK-THROUGHS
1.4 TESTING STEPS
1.4.1 Identification of Modified Units
1.4.2 Static Testing
1.4.3 Choice of Verification Methods
1.4.4 Steps in Automated Testing
1.4.5 Documentation Test
APPENDIX
REVISION HISTORY

1.0 UNIT TEST STANDARDS

1.1 INTRODUCTION AND DEFINITIONS

Unit testing shall be performed on at least 2 platforms. The major effort may be concentrated on one platform but testing on a second platform is required to ensure portability.

1.1.1 Definition of a Unit in C/C++

For purposes of this document, a "unit", in C/C++, is a single C/C++ function. The "modified units" for a tisk are the new C/C++ functions and any changed C/C++ functions. Unit testing focuses on testing thoroughly those modified units.

1.1.2 Definition of a Unit in Java

For purposes of this document, a "unit", in Java, is a single Java method. The "modified units" for a tisk are the new Java methods and any changed Java methods. Unit testing focuses on testing thoroughly those modified units.

1.2 PERSONNEL

If resources are available, it is desirable that the unit tests should be developed by someone other than the coder.

1.3 IMPLEMENTATION WALK-THROUGHS

At several points in this document a "walk-through" is mentioned. The walk-through is an informal procedure in which some experienced "mentor" reviews code and/or tests and confirms that there are no bugs. The walk-through may be conducted in person (with tester and mentor both present) or by electronic mail. Refer the the GUMP++ Process Architecture Documentation for the point in the process at which the walk-through is conducted.

1.4 TESTING STEPS

Unit testing should generally follow the steps outlined below. However the testers may change the order or perform steps in parallel if appropriate. If the code is modified (for example to fix a bug found during unit testing) ALL steps must be repeated.

1.4.1 Identification of Modified Units

The units that have been modified are found by comparing the pre-tisk baselined code with the current version. (A tool such as "diff" should probably be used.) A list of these units should be made for future reference.

1.4.2 Static Testing

Static testing tools should be used when available. The tools should be run on the pre-tisk baseline and on the current version of the code to detect any new warning messages. All such new warnings should be covered in the implementation walk-through.

1.4.3 Choice of Verification Methods

1. Units with minor changes( e.g. to strings, comments, formats, etc. ): These may be verified during the implementation walk-through without specific unit testing.
2. Units involving GUI and similar code which is hard to verify using automated drivers: This kind of code is tested by running the entire application and visually checking the results. Manual test scripts stating the sequence of test steps may be included as comments at the end of the corresponding source files.
3. Units which permit automated unit tests: These are tested using the steps described in the following section.

1. Develop black box tests. The list of test conditions should include equivalence classes, boundary value tests, and "error guessing" of unusual but problematic cases (e.g. empty files, null pointers, etc.)
2. Check the coverage of the test set, either by traceing code or by using a test coverage tool. Enhance the test set with white box tests to get full statement coverage.
3. Uncoverable statements (e.g. null return value from malloc()) should be reviewed during the implementation walk-through.

• For C/C++ by adding a test driver surrounded by #ifdef UNIT_TEST. (See example in Appendix ).
• For Java by adding a classTest() method as described in the Java Coding Standard.

1.4.5 Documentation Testing

If a tisk results in any nontrivial user documentation changes, it is recommended that the Documentation Engineer have the documentation read by someone outside the Software Engineering Team to check for clarity. The "client" could be a possible reviewer.

APPENDIX

/* File Name : UnitTestExample.c */

#include < stdio.h > 

int addTo( int preValue, operator ) 
{ 
    int postValue = preValue + operator;
    return postValue; 
} 

int subtractFrom( int preValue, operator )
{ 
    int postValue = preValue - operator;
    return postValue; 
} 

/* Compile with -D switch to run unit tests.
 *      Example : gcc -D UNIT_TEST -o example UnitTestExample.c
 */

#ifdef UNIT_TEST 
int main() 
{  
    preValue = 0; 
    operator = 5; 
    int returnValue; 

    /* Test 01 - Test function addTo() */
    returnValue = addTo( preValue, operator ); 
    if( (returnValue - operator) == 0 )
        printf( "Test 01 passed.\n" ); 
    else
        printf( "Test 01 failed.\n" ); 

    /* Test 02 - Test function subtractFrom() */
    returnValue = subtractFrom( preValue, operator );
    if( (returnValue + operator) == 0 )
        printf( "Test 02 passed.\n" );
    else 
        printf( "Test 02 failed.\n" ); 
    return 0; 
} 

/* Compile without -D switch to run main program.
 *      Example : gcc -o example UnitTestExample.c
 */

#else 
int main() 
{ 
    int accumulation = 0;
    int preValue = 0;
    int operator = 25; 
    int postValue, i; 
    for( i = 0; i < 10; i++ )      
        accumulation += addTo( preValue, operator ); 
    postValue = subtractFrom( accumulation, operator );
    printf( "%s%d\n", "postValue = ", postValue );
    return 0;
} 
#endif 

REVISION HISTORY