Scribd
Upload
47 views

Chapter 11, Unit Testing

This document discusses unit testing and the different types of tests involved at the unit level. It describes static analysis techniques like code inspection and dynamic analysis techniques like black-box and white-box testing. Black-box testing focuses on input/output behavior and uses techniques like equivalence partitioning to reduce the number of test cases. White-box testing focuses on code coverage and includes statement, loop, path, and branch testing. The same testing approaches applied at the class level for unit testing.

Uploaded by

PSIEBEL
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
47 views

Chapter 11, Unit Testing

This document discusses unit testing and the different types of tests involved at the unit level. It describes static analysis techniques like code inspection and dynamic analysis techniques like black-box and white-box testing. Black-box testing focuses on input/output behavior and uses techniques like equivalence partitioning to reduce the number of test cases. White-box testing focuses on code coverage and includes statement, loop, path, and branch testing. The same testing approaches applied at the class level for unit testing.

Uploaded by

PSIEBEL
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 10

Object-Oriented Software Engineering

Conquering Complex and Changing Systems

Chapter 11, Unit Testing

Testing Activities
Subsystem Code Subsystem Code

Unit Test Unit Test


Tested Subsystem

System Design Document

Requirements Analysis Document

User Manual

Tested Subsystem

Integration Test
Integrated Subsystems

Functional Test

Functioning System

Tested Subsystem

Subsystem Code

Unit Test

Detailed Source Code Design (whitebox) (blackbox)


Bernd Bruegge & Allen Dutoit

All tests by developer

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Testing Activities ctd


Global Requirements
Validated Functioning System PerformanceSystem

Clients Understanding of Requirements


Accepted System

User Environment

Test

Acceptance Test

Installation Test
Usable System

Tests by client Tests by developer Users understanding

Tests (?) by user


Bernd Bruegge & Allen Dutoit

System in Use
3

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Unit Testing

Informal:
Incremental coding

Static Analysis:
Hand execution: Reading the source code Walk-Through (informal presentation to others) Code Inspection (formal presentation to others) Automated Tools checking for syntactic and semantic errors departure from coding standards

Dynamic Analysis:
Black-box testing (Test the input/output behavior) White-box testing (Test the internal logic of the subsystem or object) Data-structure based testing (Data types determine test cases)
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4

1. Select what has to be measured Code tested for correctness with respect to:
requirements architecture detailed design

The 4 Testing Steps (presented before)

3. Develop test cases


A test case is a set of test data or situations that will be used to exercise the unit (code, module, system) being tested or about the attribute being measured

4. Create the test oracle


An oracle contains of the predicted results for a set of test cases

2. Decide how the testing is done for each level of testing


Code inspection Black-box, white box, Select integration testing strategy (big bang, bottom up, top down, sandwich)
Bernd Bruegge & Allen Dutoit

I.e., expected output for each test

The test oracle has to be written down before the actual testing takes place This is the difficult step
5

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Black-box Testing

Focus: I/O behavior. If for any given input, we can predict the output, then the module passes the test.
Almost always impossible to generate all possible inputs ("test cases") need techniques to define the input values

Derive tests using the detailed design Goal: Reduce number of test cases by equivalence partitioning:
Divide input conditions into equivalence classes Choose test cases for each equivalence class. (Example: If an object is supposed to accept a negative number, testing one negative number is enough)

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Black-box Testing (Continued)

Selection of equivalence classes (No rules, only guidelines):


Input is valid across range of values. Select test cases from 3 equivalence classes:

Below the range Within the range Above the range

Input is valid if it is from a discrete set. Select test cases from 2 equivalence classes:

Valid discrete value Invalid discrete value

Another solution to select only a limited amount of test cases:


Get knowledge about the inner workings of the unit being tested => white-box testing

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

White-box Testing Focus: Thoroughness (Coverage) Derive tests using the source code Four types of white-box testing Statement Testing Loop Testing Path Testing Branch Testing

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

White-box Testing (Continued)


Statement Testing:
Select and test single statements

Loop Testing:
Cause execution of the loop to be skipped completely

Note. cannot do this on repeat until loops

Loop to be executed exactly once Loop to be executed more than once


Path testing:
Make sure all paths in the program are executed

Branch Testing (Conditional Testing): Make sure that each possible outcome from a condition is tested at least once
if ( i = TRUE) printf("YES\n");else printf("NO\n"); Test cases: 1) i = TRUE; 2) i = FALSE

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Unit Level

We can use the same testing approaches (whitebox, blackbox) in testing the classes The same testing activities occur, but now they are applied at a lower level of abstraction

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

10

You might also like