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.


Agenda

• Products & Deliverables

• Testing Classes

• What is Unit Testing?

• Testing Callable Modules

• Putting it All Together


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.


What Is A Unit?

• Named software element with properties and behavior

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


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


Elementary Units

• Form• Field

• Navigation Button

• Operation Button

• Database• Field

• Stored Procedure

• Query

• Program Code• Main

• Method

• Function

• Script


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


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.


Agenda


• Testing Classes



• Putting It All Together


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


Recommended Practice

Analysis

Design

Implementation

Execution

Evaluation

Decision Table

[Test Script, Driver]

#Bugs Found

Worksheet(Test Cases)

Worksheet(Results)

Specification,

Code


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


Product Templates

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

• Decision table

• Unit test cases (functional, boundary)

• Unit test worksheets


Agenda


• Testing Callable Subprograms/Methods



• Testing Database Procedures


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.


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


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


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


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!!


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


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


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


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


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.


Your Turn -- Test Driver Design

DriverPayDate

GenPayroll Pay

RateHours

GrossPay

file"time.dat"

database"emp.db"

file"payreg.dat"

Verification

Set-Up


Agenda


• Testing Classes


• Testing Callable Modules -- DB Proc



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.


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.


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).


Agenda


• Testing Classes





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.


Testing Classes -- Drivers(Black-Box)

ClassTest

Driver Method Args/Results

Test setData

Test Set Results

Class

Class-state

Method(s)


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.


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


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;



… 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;


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


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.


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


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.



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;



// 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;


Agenda


• Testing Classes





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!


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.


SOLUTIONS TO EXERCISES


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

Documents

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