CEN 5070 Software V&V Spring 2002 Testing 102 -- Internal Modules © 2001-2002, Dr. E.L. Jones

CEN 5070 Software V&VSpring 2002

Testing 102 -- Internal Modules© 2001-2002, Dr. E.L. Jones

1/2002 Testing 102 -- Internal Modules 2

Purpose

This lecture prepares the student to practice unit testing on a project by applying the concepts covered in the Software Unit Test Concepts course.

1/2002 Testing 102 -- Internal Modules 3

Agenda

• Products & Deliverables

• Testing Classes

• What is Unit Testing?

• Testing Callable Modules

• Putting it All Together

1/2002 Testing 102 -- Internal Modules 4

What is Unit Testing?

• Executing a software element to determine whether it meets its specification

• Executing a software element to discover defects or anomalies

• Inspecting software element code to discover defects or anomalies.

1/2002 Testing 102 -- Internal Modules 5

What Is A Unit?

• Named software element with properties and behavior

• Separately invokable• Performs single function• Logically cohesive set of the above

1/2002 Testing 102 -- Internal Modules 6

Examples of Units

• User-Visible software elements• Fields on forms

• Buttons on forms

• Entire forms (reports)

• Program-Internal software elements• Subprograms (procedures, functions, mains)

• Classes

• Databases

1/2002 Testing 102 -- Internal Modules 7

Elementary Units

• Form• Field

• Navigation Button

• Operation Button

• Database• Field

• Stored Procedure

• Query

• Program Code• Main

• Method

• Function

• Script

1/2002 Testing 102 -- Internal Modules 8

Can A Unit Be Bigger?

• Yes, but beware of pitfalls• Complex units are hard to test• Repetition of tests more costly• Tendency to focus on the easy part

• A composite unit (naturally related parts)• A class = methods + data• A form = data fields + action buttons

• One test script for hierarchical testing of parts, then whole

1/2002 Testing 102 -- Internal Modules 9

Objective

The practice of unit testing adds value to the development process by surfacing areas of incompleteness, inaccuracy or ambiguity. Extensive use of aids (checklists, worksheets) minimizes the effort but encourages thorough analysis.

1/2002 Testing 102 -- Internal Modules 10

Agenda

• Products & Deliverables

• Testing Classes

• What is Unit Testing?

• Testing Callable Modules

• Putting It All Together

1/2002 Testing 102 -- Internal Modules 11

Required Elements of Testing Practice

• Specification for the software

• Process for designing test cases

• Repeatable process for designing, running and evaluating tests

• Accountable artifacts of testing activities

• Economical use of human, time and computing resources

1/2002 Testing 102 -- Internal Modules 12

Recommended Practice

Analysis

Design

Implementation

Execution

Evaluation

Decision Table

[Test Script, Driver]

#Bugs Found

Worksheet(Test Cases)

Worksheet(Results)

Specification,

Code

1/2002 Testing 102 -- Internal Modules 13

Products vs Deliverables

• A Product is an informal artifact from applying a testing process. • belongs to the developer

• a physical form, not necessarily electronic

• A Deliverable is an artifact that attests to the application of the testing process• belongs to the team

• an attesting signature required

1/2002 Testing 102 -- Internal Modules 14

Product Templates

• Templates will be provided for these test products• Black-box Schematic

• Decision table

• Unit test cases (functional, boundary)

• Unit test worksheets

1/2002 Testing 102 -- Internal Modules 15

Agenda

• Products & Deliverables

• Testing Callable Subprograms/Methods

• What is Unit Testing?

• Testing Callable Modules

• Testing Database Procedures

1/2002 Testing 102 -- Internal Modules 16

Testing Modules -- Overview

Directly testing callable modules requires isolating the module and capturing the context in which it is called. Additional effort is required for this "code level" testing, but certain aspects can be automated, providing repeatability, efficiency and documentation.

1/2002 Testing 102 -- Internal Modules 17

Testing Modules -- Drivers

A test driver executes a unit with test case data and captures the results.

Driver

Test setData External

EffectsUnitArguments

ResultsTest Set Results

1/2002 Testing 102 -- Internal Modules 18

Implementing Test Drivers

• Complexity– Arguments/Results only– Special set-up required to execute unit– External effects capture/inquiry– Oracle announcing "PASS"/"FAIL"

• Major Benefits– Automated, repeatable test script– Documented evidence of testing– Universal design pattern

1/2002 Testing 102 -- Internal Modules 19

Test Driver for Unit Pay

Driver D_payuses unit_environment E;{ declare Hrs, Rate, expected; testcase_no = 0; open tdi_file("tdi-pay.txt"); open trs_file("trs-pay.txt"); while (more data in tdi_file) { read(tdi_file, Hrs, Rate); read(tdi_file, expected);

testresult = pay(Hrs, Rate); write (trs_file, testcase_no++, Hrs, Rate, expected, testresult); }//while close tdi_file, trs_file; }//driver

1/2002 Testing 102 -- Internal Modules 20

Test Driver Files (Pay)

Test Data FileFile name: tdi-pay.txtFormat: (test cases only) rate hours expected-pay

File content:10 40 400 10 50 55010 0 0

------Note: No environment setup.

Test Results FileFile name: trs-pay.txtFormat: case# rate hours exp-pay act-pay

File content:1 10 40 400 4002 10 50 550 5003 10 0 0 0

------Note: Results file must be inspected for failures.

PassFailPass

Test Script!!

1/2002 Testing 102 -- Internal Modules 21

Testing Modules -- Drivers with Test Environment Set-Up

The driver initializes the execution environment of the unit, and examines it after testing completes.

External

EffectsUnit

Driver

Test setData

ArgumentsResults

Test Set Results

Environment

ExecutionEnvironment

Setup / Inquire

1/2002 Testing 102 -- Internal Modules 22

Test Driver Files (Pay2) (Accumulates grand total of pay amounts)

PassFailPass

Fail

Test Data FileFile name: tdi-pay.txtFormat: initial_pay_total final_pay_total {rate hours expected-pay}

File content:1000 195010 40 400 10 50 55010 0 0

------Note: Environment setup = initialize global variable.

Test Results FileFile name: trs-pay.txtFormat: case# rate hours exp-pay act-pay env_init, env_exp, env_final

File content:1 10 40 400 4002 10 50 550 5003 10 0 0 0

1000 1950 1900------Note: Results file must be inspected for failures.

Test Script!!

Initial / ExpectedGrand Total

1/2002 Testing 102 -- Internal Modules 23

Test Driver for Pay2(Accumulates grand total of pay amounts)

Driver Dglobal total_pay;{ open tdi_file ("tdi-pay2.txt"); open trs_file("trs-pay2.txt");

//Set up unit_environment E read (tdi_file, initial_tot, exp_tot); total_pay = initial_tot; testcase_no = 0; while (more data in tdi_file) { read (tdi_file, Hrs, Rate); read (tdi_file, expected);

testresult = pay2(Hrs, Rate); write (trs_file, testcase_no++, Hrs, Rate, expected, testresult); }//while

final_tot = total_pay; write(trs_file, initial_tot, exp_tot, final_tot); close tdi_file, trs_file; }//driver

1/2002 Testing 102 -- Internal Modules 24

Unit Test Driver Design -- Test Environment Set-Up/Inquiry

Driver Duses unit_environment E;{ open tdi_file (filename); open trs_file (filename);

//Set up unit_environment E read (tdi_file, E_initial, E_expect); E.set (E_initial); testcase_no = 0; while (more data in tdi_file) { read (tdi_file, testdata); read (tdi_file, expected);

testresult = unit(testdata); write (trs_file, testcase_no++, testdata, expected, testresult); }//while

E.get(E_final); write (trs_file, E_initial, E_expect, E_final); close tdi_file, trs_file; }//driver

1/2002 Testing 102 -- Internal Modules 25

Your Turn -- Test Driver Design

Unit GenPayroll(PayDate) computes pay for all employees who

submitted time records (file "time.dat") for the previous week. All

employees are hourly. Employee IDs, pay rates, and YTD earnings

are stored in the Employee database ("emp.db"). GenPayroll calls

unit Pay (Hours, Rate) to compute gross pay. Next, GenPayroll

deducts a flat 10%, then writes PayDate, EmployeeID, Hours, Rate,

GrossPay, Deductions, and NetPay to the Payroll Register (file

"payreg.dat"). Finally, GenPayroll updates YTD-Earning for the

employee. -------------------------------

Design the test driver for GenPayroll. Focus on (1) required set-

up; (2) data preparation; (3) test execution; (4) verification of

results.

1/2002 Testing 102 -- Internal Modules 26

Your Turn -- Test Driver Design

DriverPayDate

GenPayroll Pay

RateHours

GrossPay

file"time.dat"

database"emp.db"

file"payreg.dat"

Verification

Set-Up

1/2002 Testing 102 -- Internal Modules 27

Agenda

• Products & Deliverables

• Testing Classes

• What is Unit Testing?

• Testing Callable Modules -- DB Proc

• Putting It All Together

1/2002 Testing 102 -- Internal Modules 28

Testing DB Procedures -- OverviewSince the database plays a central role in a system, database procedures should be tested carefully. Automating this testing permits thorough testing and efficient verification via database queries. Trusted database code is a candidate for reuse.

1/2002 Testing 102 -- Internal Modules 29

Testing DB Procedures -- Process

• Set-Up• Initialize DB to baseline (or error) state

• Run Test Script (manual/automated)• Run Verification Script (manual/auto)

• Verify queries, updates

• A test driver can combine the test and verification scripts into a single, comprehensive test.

1/2002 Testing 102 -- Internal Modules 30

Testing Callable Units -- SummaryA test driver is a reusable design pattern. Test drivers give code-level visibility into the behavior of units, while documenting the testing process. A unit driver can be used for indirect testing of lower level modules. The unit test driver can be extended to test complex units (classes).

1/2002 Testing 102 -- Internal Modules 31

Agenda

• Products & Deliverables

• Testing Classes

• What is Unit Testing?

• Testing Callable Modules

• Putting It All Together

1/2002 Testing 102 -- Internal Modules 32

Testing Classes -- Overview

A class is a collection of elementary units (methods) sharing an execution context. As with forms, testing a class requires unit testing of its methods along with an "integration" test of the overall semantics of the class. The approach for unit testing is extended for classes.

1/2002 Testing 102 -- Internal Modules 33

Testing Classes -- Drivers(Black-Box)

ClassTest

Driver Method Args/Results

Test setData

Test Set Results

Class

Class-state

Method(s)

1/2002 Testing 102 -- Internal Modules 34

Example -- Stack Class

class Stack{ public: Stack(); void push(int n); int pop(); int top(); bool empty(); private: int Size; int Top; int Values[100];};

Notes:

(1) Class state -- variables Size, Top and the first 'Size' values in array Values.(2) Methods push and pop modify class state; top and empty inquire about the state.(3) Stack does not require any test environment of its own.(4) Class state HIDDEN from test, i.e., black box.

1/2002 Testing 102 -- Internal Modules 35

Test Driver Files (Stack class)

Test Data File (tdi-stack.txt)File content:----- 1 8 1 7 3 7 2 7 2 8 4 true------Note: No test environment setup.Methods: 1-push, 2-pop, 3-top, 4-empty

Test Results File (trs-stack.txt)File content:-----1 1 8 2 1 73 3 7 84 2 7 85 2 8 76 4 1------Note: Results file must be inspected for pass/fails.

--- Top should be 7.

--- Push .

--- Pop, should be 8.--- Stack should be empty.

FailFailFailPass

1/2002 Testing 102 -- Internal Modules 36

Class Test Driver Design

Driver dCuses class C{ c = new (C); testcase_no = 0; open tdi_file("tdi_stack.txt"); open trs_file("trs_stack.txt"); while (more data in tdi_file) { op = read(tdi_file); switch (op) {

case 1: //Push. read(tdi_file, value); c.push(value); write(trs_file, testcase_no, 1, value); break;

case 2: //Pop. read(tdi_file, expect); value = c.pop(); write(trs_file, testcase_no, 2, expect, value); break;

1/2002 Testing 102 -- Internal Modules 37

Class Test Driver Design

… default:

} //switch

}//while

close tdi_file, trs_file;

}//class-driver

case 3: //Top. read(tdi_file, expect); value = c.top(); write(trs_file, testcase_no, 3, expect, value); break;

case 4: //Empty. read(tdi_file, expect); value = c.empty(); write(trs_file, testcase_no, 4, expect, value); break;

1/2002 Testing 102 -- Internal Modules 38

Implementing Class Test Drivers

• Interactive vs Batch (files) • Extend Unit Driver

– switch to handle multiple methods– Method-specific test cases– Method interactions tested– All results stored in common results file

• Major Benefits -- comprehensive driver– Automated, repeatable, documented– Minimized set-up

1/2002 Testing 102 -- Internal Modules 39

Class Test Driver -- Summary

• Data Driven -- flexible, extensible

• Varying levels of detail– black-box (method calls, no class state)

– clear-box (class state, advanced topic)

– global effects (test environment)

• A driver is a reusable pattern for testing.

1/2002 Testing 102 -- Internal Modules 40

Clear-Box Class Testing -- Drivers Use Internal State

External

Test Env

ClassTest

Driver Method Args/Results

Test setData

Test Set Results

Setup / InquireInternalTest Env

ClassTest Env

Class-state

Method(s)

Class StateSetup/Inquire

1/2002 Testing 102 -- Internal Modules 41

Example -- Stack Class

class Stack{ public: Stack(); void push(int n); int pop(); int top(); bool empty(); void SetState(int,int,int[]); void GetState(int &,int &,int[]); private: int Size; int Top; int Values[100];};

Notes:

(1) Class state -- variables Size, Top and the first 'Size' values in array Values.(2) Methods push and pop modify class state; top and empty inquire about the state.(3) "Hooks" can be created to set and retrieve the class state.(4) Stack does not require any test environment of its own.

1/2002 Testing 102 -- Internal Modules 42

Class Test Driver Design

Driver dCuses Test_Env T;uses class C{ // Set up external environment // c = new (C); testcase_no = 0; open tdi_file (filename); open trs_file (filename)

case -4: //Set test env// read(tdi_file. t_env); T.setenv(t_env); break;case -3: //Get test env// T.getenv(t_env); write(trs_file, t_env); break;case -2: //Set class state// read(tdi_file, c_state); c.setstate(c_state); break;

1/2002 Testing 102 -- Internal Modules 43

Class Test Driver Design

// If the internal state of the class // must be set or checked, a (-2) // precedes case "m", and a (-1) // follows case "m".

// Remaining methods … // default: } //switch }//while close tdi_file, trs_file; }//driver

case -1: //Get class state. c.getstate(c_state); write(trs_file, c_state); break;

case m: // test class method #m. read(tdi_file, args); read(tdi_file, expect); result = method(args); write (trs_file, testcase_no++, args, expect, result); break;

1/2002 Testing 102 -- Internal Modules 44

Agenda

• Products & Deliverables

• Testing Classes

• What is Unit Testing?

• Testing Callable Modules

• Putting It All Together

1/2002 Testing 102 -- Internal Modules 45

Putting It Together

• Test design is the central thing

• Test scripts define the sequence of test

actions -- a repeatable process

• Test drivers automate test scripts and

produce test documentation

• Automation is reusable!

1/2002 Testing 102 -- Internal Modules 46

CONCLUSION

Unit testing lays the foundation for software testing. The techniques covered in this class extend from simple to complex units and, as we will see, to integration testing. Worksheets and templates facilitate the process while guiding the tester through a systematic design process.

1/2002 Testing 102 -- Internal Modules 47

SOLUTIONS TO EXERCISES

1/2002 Testing 102 -- Internal Modules 48

Unit Test Driver Design -- Global Pre/Post Conditions

(pattern)Driver Duses unit_environment E;{ open testdata_file(filename); open testresults_file(filename); // Set up unit_environment E\ read (testdata_file, E_initial); E.set (E_initial );

testcase_no = 0; while (more data in testdata_file) { read(testdata_file, testdata); read(testdata_file, expected);

testresult = unit(testdata); write (testresults_file, testcase_no++, testdata, expected, testresult); }//while E.get(E_final); write(testresults_file, E_initial, E_expect, E_final) close testdata_file, testresults_file; }//driver