UNIT TESTING

“In God we trust; All else we test”

Dr. Vani Vasudevan Iyer

Objective of Testing
■ Bug: Defect in software that causes the program to
malfunction

■ Bugs in software often lead to frustration for the end

user of the software. Bugs in critical software, where
financial transactions and huge amounts of money are
involved may even lead to huge losses to the customer

■ It is the responsibility of the Software Engineer to

deliver a bug free code

Dr.Vani Vasudevan 2
Definitions of Testing

■ “The process of analyzing a software item to detect the

differences between existing and required conditions (i.e.,
bugs) and to evaluate the features of the software item”
(IEEE 1993)

■ “The process of analyzing a program with the intent of finding

errors” (Myers 1979)

Dr.Vani Vasudevan 3
Unit Testing (1 of 2)

■ Each individual unit of code is tested to ensure that it performs its

intended functionality

■ Unit tests are done on their respective modules by Software Engineer

who has written code

■ Unit tests are created using some techniques which ensure that all
logical paths of the code unit are tested, and maximum number of errors
can be detected by executing these tests

■ The Unit Test Plan (UTP) prepared towards the end of the design phase is
used for Unit Testing the software or code

Dr.Vani Vasudevan 4
Unit Testing (2 of 2)

■ Any defects found during unit testing are logged in the Defect
Tracking System (DTS) and they are tracked till the defects are
removed from the code

■ Test Case: A set of inputs, execution preconditions, and expected

outcomes developed for a particular objective, such as to
exercise a particular program path or to verify compliance with a
specific requirement

■ Precondition for a test case: A precondition for a test case is any

activity that is required to be completed in order for the stage to
be set for the test case execution. A precondition is one without
which the test procedure cannot be executed

Dr.Vani Vasudevan 5
 Documenting Test Cases (1 of 1)

■ Very often test plans contain hundreds of test

cases and so it is essential to keep documentation
Sl Test
ofcase Testclear andPre-
test cases Expected
in simplest terms as Reference to
No name Procedure condition Result Detailed Design /
possible Spec Document

Test Plan

Dr.Vani Vasudevan 6
Documenting Test Cases (2 of 2)
■ A test case name should be of the following format.
<Module Name>_<Function Name>_<Test Procedure>,
where
– Module Name is the name of the module the test case tests
– Function Name is the name of the function or functionality the test case tests
– Test Procedure is a term or word which briefly represents what the test case is trying to do

■ Test Procedure (Condition to be tested): Explains briefly but clearly, what the test case is
doing.

■ Input Condition: Input Condition contains details of any specific preconditions

■ Expected Result: sometimes known as Pass/Fail Criteria

Dr.Vani Vasudevan 7
Types of Test Cases
■ Test cases are of two types:

– Positive test case: A positive test case is one which is

designed in such a way that the program or module being
tested succeeds. (A valid input is passed to get a valid
result.)

– Negative test case: A test case which is designed in such a

way that the program or module being tested gives
appropriate error code on an invalid input. (Usually an
invalid input or condition is created in negative test cases.)
Negative test cases test the robustness of the program

Dr.Vani Vasudevan 8
Identifying Test Cases

■ Boundary Value Analysis

■ Equivalence Partitioning

■ Logic Coverage

■ Random Generation

Dr.Vani Vasudevan 9
Boundary Value Analysis (1 of 5)

■ A boundary value is one which indicates the border (or

the limit) of a value
■ Test cases that explore boundary values have the
highest payoff in terms of detecting bugs, as the most
common errors occur at the boundary level
■ Boundary value test cases are those which test the
function or field using values that
– Lie on the boundary
– Just above the boundary
– Just Below the boundary

Dr.Vani Vasudevan 10
 Boundary Value Analysis (2 of 5)
■ For example if an input condition specifies that the range of
values of the input variable items must be from 0 to 100, the
boundary values would be -1, 0,1,99,100 and 101

Valid Range of Input Values

Lower Upper
Lower Limit Lower Upper Limit Upper
Limit -1 Limit + 1 Limit -1 Limit + 1

Dr.Vani Vasudevan 11
 Boundary Value Analysis (3 of 5)
/**********************************************************************************
* Function: fnFindGrade
* Description:Given the percentage score of student,

* returns the grade of the student.

* Criteria for Grades:

* A - 80 to 100

* B - 65 to 79
* C - 55 to 64

* D - 40 to 54
* E - 0 to 39
* Input Parameters:

* int iPercentScore - Percentage scored by the student.

*
* Returns:'A', 'B', 'C', 'D' and 'E' on passing

* valid percentage. 'Z' if input percentage is

* invalid (less than zero or greater than 100)

************************************************************************************/

char fnFindGrade (int iPercentScore) {

Dr.Vani Vasudevan 12
...
Boundary Value Analysis (4 of 5)
■ A score expressed in percentage can be only
between 0 and 100. Any value beyond 0 and 100
are considered as invalid and the function should
return the grade as ‘Z’

■ To start with, let us test this function for the

boundary values 0 and 100. So, we can consider
the values -1, 0, 1 and 99, 100, 101 in this case.
Since the function is simple, it does not require any
preconditions

Dr.Vani Vasudevan 13
Sl Test case name Test Procedure Pre- Expected Reference
N conditio Result to Detailed
o n Design /
Boundary Value Analysis (5 of 5) Spec
Document
1 fnFindGrade_MinusO Call fnFindGrade with None Function fnFindGrade
ne iPercentScore = -1 returns ‘Z’.
(Negative
Test case)
2 fnFindGrade_0 Call fnFindGrade with None Function fnFindGrade
iPercentScore = 0 returns ‘E’
3 fnFindGrade_1 Call fnFindGrade with None Function fnFindGrade
iPercentScore = 1 returns ‘E’
4 fnFindGrade_99 Call fnFindGrade with None Function fnFindGrade
iPercentScore = 99 returns ‘A’
5 fnFindGrade_100 Call fnFindGrade with None Function fnFindGrade
iPercentScore = 100 returns ‘A’
6 fnFindGrade_101 Call fnFindGrade with None Function fnFindGrade
iPercentScore = 101 returns ‘Z’.
(Negative
test case)

Dr.Vani Vasudevan 14
 Equivalence Partitioning (1 of 3)
■ This consists of dividing all possible inputs into a set of classes, where
either all inputs that fall into a given class are valid or all are invalid.
Then selecting a few test cases from each class is sufficient.
■ For example if an input condition specifies that the range of values of the
input variable items must be from 1 to 999, one valid equivalence class
would be 1<=items<=999 and 2 invalid equivalence classes would be
items<1 and items>999

■ Most of the equivalence partition test cases are positive test cases

■ The values chosen for Equivalence partition should not be a boundary

value

Dr.Vani Vasudevan 15
 Equivalence Partitioning (2 of 3)
Sl Test case name Test Procedure Pre- Expected Reference to
No condition Result Detailed
Design / Spec
Document
1 fnFindGrade_E20 Call fnFindGrade None Function fnFindGrade
with iPercentScore = returns ‘E’
20

2 fnFindFrade_D48 Call fnFindGrade None Function fnFindGrade

with iPercentScore = returns ‘D’
48

3 fnFindGrade_C59 Call fnFindGrade None Function fnFindGrade

with iPercentScore = returns ‘C’
59
4 fnFindGrade_B71 Call fnFindGrade None Function fnFindGrade
with iPercentScore = returns ‘B’
71
5 fnFindGrade_A90 Call fnFindGrade None Function fnFindGrade
with iPercentScore = returns ‘A’
90

Dr.Vani Vasudevan 16
 Equivalence Partitioning (3 of 3)
Sl Test case name Test Procedure Pre- Expected Reference to
No condition Result Detailed
Design / Spec
Document
6 fnFindGrade_Invalid_Minus30 Call fnFindGrade None Function fnFindGrade
with iPercentScore = returns ‘Z’.
-30 (Negative
Test case)
7 fnFindGrade_Invalid_300 Call fnFindGrade None Function fnFindGrade
with iPercentScore = returns ‘Z’.
300 (Negative
Test case)

Dr.Vani Vasudevan 17
 Logic Coverage (1 of 4)
■ This technique aims to generate enough test cases so that an appropriately
defined coverage criterion is met

■ Criterion: Every statement in the program must be executed at least once,

every branch in the program must be executed at least once, or every path
in the program must be executed at least once
■ Example:
– The User Interface for searching the address book should be very friendly and
should use the following search criteria
– Can search the address book based on one or more of the following fields:
■ E-mail Id of the person
■ Name of the person
■ Employee Number of the person
– Can accept one or more fields for search criteria
– Accepts partial values for E-mail and Name

Dr.Vani Vasudevan 18
Logic Coverage (2 of 4)

Dr.Vani Vasudevan 19
Logic Coverage (3 of 4)
Sl Test case name Test Procedure Pre- Expected Result Reference to
No cond Detailed
ition Design
1 addrbook_all_blank All the fields are None Address book must Address book
kept blank and display an Error Module
click on ‘Search…’ message and prompt
user to enter at least
one field.
(Negative Test case)
2 addrbook_empno_ok Type in an None Address book must Address book
employee number fetch one (only one) Module
(Ex: 7342) and then entry of the person
click on ‘Search…’ with that employee
number
3 addrbook_empno_fail Type in an invalid None Address book must
employee number fetch zero records
and then click and display that
‘Search…’ record is not found.
(Negative Test case)
4 addrbook_email_full Type in a full e- None Address book must Address book
mail id (Ex: fetch one (only one) Module
nagendra_setty) entry of the person
and then click on corresponding to
‘Search…’ the e-mail Id.

Dr.Vani Vasudevan 20
Logic Coverage (4 of 4)
5 addrbook_email_partial Type in a partial None Address book Address book
but valid e-mail id should fetch one or Module
(Ex:nagen) and more records
then click on where e-mail id
‘Search…’ begins with the
same letters.
6 addrbook_email_fail Type in an invalid None Address book must Address book
name (Say jhsgjss) fetch zero records Module
and click on and display that
‘Search…’ record is not found.
(Negative Test
case)
7 addrbook_name_full Type in a full None Address book must Address book
name (Ex: fetch one (only one) Module
Nagendra R Setty) entry of the person
and then click on with that name.
‘Search…’
8 addrbook_name_partial Type in a Partial None Address book Address book
name (Ex: should fetch one or Module
Nagend) and then more records
click on ‘Search…’ where name begins
with the same
letters.

Dr.Vani Vasudevan 21
Random Generation

■ Data is generated randomly either using a tool or manually.

This is the simplest method but not the most efficient

Dr.Vani Vasudevan 22
Implementing Test Cases (1 of 3)
■ Unit Tests can be executed either manually or can be automated

■ Usually, testing of User Interfaces (screens) is done manually

■ Testing a function or piece of code can be automated

■ The simplest way to automate is to write a program or scripts

(batch/command scripts) which test the function or the piece of code

■ A test script or test program incorporates all the input test data and pre-
conditions (if any) documented in the Unit Test Plan before executing the test

Dr.Vani Vasudevan 23
Implementing Test Cases (2 of 3)
Sl Test case name Test Procedure Pre- Expected Result Reference to
No condition Detailed
Design
6 fnFindGrade_101 Call fnFindGrade with None Function returns fnFindGrade
iPercentScore = 101 ‘Z’. (Negative
test case)

■ Within the test function, when the test case does not result in
the expected output, it is always a good practice to print all
relevant values and information which can help the Software
Engineer to understand the defect and to solve it

Dr.Vani Vasudevan 24
Implementing Test Cases (3 of 3)
int testfnFindGrade_101 () {

const TEST_PASSED 0

const TEST_FAILED -1

char cRet;

/* Call fnFindGrade with Input value = 101 */

cRet = fnFindGrade (101);

/* Expected Test Result: 'Z' */

if (cRet == 'Z') { /* TEST PASSED! */

System.out.println ("Test testfnFindGrade_101 PASSED!\n");

return TEST_PASSED;

else { /* TEST FAILED! */

System.out.println ("ERROR: testfnFindGrade_101 FAILED!\n”);

System.out.println (" testfnFindGrade_101: Ret Value = %c\n", cRet);

return TEST_FAILED;

} Dr.Vani Vasudevan 25
Recording / Logging a Defect
■ Any defect found in code or document must be recorded

■ Recording of defects will ensure that the defects

detected are not lost and also ensures that they are
tracked till the defects are removed completely

■ Defect data can also be used to do an analysis, which

will help improve the process of writing code and testing

Dr.Vani Vasudevan 26
Defect Tracking System
■ Most software companies have a dedicated system, for logging
and tracking defects

■ Most defect tracking systems can also do detailed analysis of the

defects to help a project take corrective action in due course of
time.

■ In the absence of a Defect Tracking System, an MS Excel sheet

(spreadsheet) is maintained to log and track defects

■ When testing or code review is done and defects are found,

defects are logged

Dr.Vani Vasudevan 27
 A sample defect tracking Excel
sheet (1 of 2)
Defe Submitted Description Detected Assigned Type of Severity Impact Priority Injected Action Notes
ct # by Stage To Defect Stage Taken

1 Vani V When 100 is Unit Martin Logical Medium Medium Medium Coding To be Addition
passed for Testing Error Fixed al notes if
iPercentScore any
fnFindGrade
returns ‘Z’

Dr.Vani Vasudevan 28
A sample defect tracking Excel
sheet (2 of 2)
■ A defect log captures some of the following information:
– Defect Number or Id: The number or Id which identifies the defect
– Submitted by: Person who found the defect
– Description: A detailed description of the defect, along with screen shots or logs excerpts and
any other information
– Detected Stage: The stage at which defect was detected
■ Example: Unit Testing, Code Review etc
– Assigned to: The developer who has to remove this defect
– Type of defect: Type of defect tells about the nature of the defect
■ Example: Coding Standards related, Logical Error
– Severity: How severe the defect is to the software application
■ Example: Cosmetic, Major, Minor and Not Applicable
– Impact: The impact of this defect on the software application
■ High, Medium, Low
– Injected Stage: The stage of software life cycle where this defect might have been introduced
■ High Level Design, Detailed Design, Coding etc

Dr.Vani Vasudevan 29
CODE REVIEW
Code Review (1 of 3)
■ A process where several people offer constructive criticism of a Software
Engineer’s code with a view to simplify it, to make it more efficient and to
eliminate errors

■ All technical reviews are based on the idea that Software Engineers may
overlook some of the trouble spots in their work, and other people don’t
have the same blind spots. So it is beneficial to have someone else look
at their work

■ An essential part of the Build Phase which helps make code bug-free to
a great extent

Dr.Vani Vasudevan 31
Code Review (2 of 3)
■ Locates or identifies potential bugs and failure
points before the code is sent to the user

■ Note: The person who wrote the code and the

person doing the code review must understand that
Code Review comments are about the code and not
the person who wrote the code. Code Review helps
to make the code better

Dr.Vani Vasudevan 32
Code Review (3 of 3)
■ Types:
– Self Code Review: The person who wrote code reviews his/her own
code using the code review checklist. Defects are fixed as they are
found

– Peer Code Review: The team member reviews the code written by
another team member using the code review checklist

– Expert Code Review: Another person, who is an expert, reviews the

code using the code review checklist. Defects are logged into a
Defect Tracking System, and tracked to closure. The person who
wrote the code has to remove the defects from the code (not the
Reviewer)

Dr.Vani Vasudevan 33
Pre-Requisites for Code Review
The code has to meet these pre-requisites before it can be reviewed.

– Does the code build without any errors and warnings?

– Has the developer unit tested the code?
– Does the source file start with appropriate header ,footer and other
information?
– Is the Code readable?
– Can the reviewer understand the code easily?

If the code does not meet any of the above mentioned pre-requisites, it
should be sent back to the Software Engineer.

Dr.Vani Vasudevan 34
Code Review Checklist
Considers following points for review:

■ Reviewing Comments and Coding Conventions

■ Reviewing Error Handling
■ Reviewing Control Structures
■ Reviewing Functions /Methods
■ Reviewing Code Performance Aspects
■ Reviewing Math related aspects

Dr.Vani Vasudevan 35
Summary

■ Unit Testing
■ Code Review

Dr.Vani Vasudevan 36