Unit Testing

Course Code: CSC4133 Course Title: Software Quality and Testing

Dept. of Computer Science

Faculty of Science and Technology

Lecturer No: 13 Week No: 8 Semester: Fall 2021-22

Lecturer: S.M. Abdur Rouf Bhuiyan [arouf@aiub.edu]
Lecture Outline

• Concept of Unit Testing

• Static Unit Testing
• Formal Code Review
• Defect Prevention
Objectives and Outcomes
• Objectives: To understand the basic concept of unit
testing, to understand the difference between static
and dynamic unit testing, to understand the formal
code review process.
• Outcomes: Students are expected to be able to explain
unit testing, be able to explain how static and dynamic
unit testing are conducted, be able to explain the
formal code review process and the different roles and
responsibilities in a formal code review.
 Concept of Unit Testing
• Unit testing tests a small software unit at a time, which is
typically performed by the individual programmer who
implemented the unit.
• Unit testing typically focuses on the implementation details and
uses WBT technique, with various coverage criteria as the exit
criteria.
• Unit testing typically focuses on the executable statements and
related control & data elements.
• BBT could also be performed on the unit, while focusing on the
input-output relations.
Static Unit Testing

• Static Unit Testing

 Code is examined over all possible behaviors that
might arise during run time
 Code of each unit is validated against requirements
of the unit by reviewing the code
Dynamic Unit Testing

• Dynamic Unit Testing

 A program unit is actually executed and its
outcomes are observed
 One observe some representative program
behavior, and reach conclusion about the quality of
the system
Which one to conduct?
Static or Dynamic Unit Testing?

• Static unit testing is not an alternative to dynamic unit

testing.
• Static and Dynamic analysis are complementary in
nature.
• In practice, partial dynamic unit testing is performed
concurrently with static unit testing. It is recommended
that static unit testing be performed prior to the
dynamic unit testing.
 Unit Testing
• Unit testing is the testing of one individual unit or component.
• A unit is the smallest testable part of an application like functions/methods,
classes, procedures.
 A unit may be an individual function, method, procedure, module, or object
• Unit testing is a method by which individual units of source code are tested to
determine if they are fit for use.
• Unit tests are basically written and executed by software developers to make
sure that code meets its design and requirements and behaves as expected.
• The goal of unit testing is to segregate each part of the program and test that
the individual parts are working correctly.
 Unit Testing
• What method/technique is used for unit testing?
Unit Testing is usually performed by using the White Box
Testing technique.
• When is it performed?
 Unit Testing is the first level of testing and is performed prior
to Integration Testing.
• Who performs it?
 Unit Testing is normally performed by software developers
themselves. In rare cases it may also be performed by
independent software testers.
 Static Unit Testing

• In static unit testing, code is reviewed by applying

techniques:
 Inspection: It is a step by step peer group review of a work
product, with each step checked against pre-determined
criteria. Inspection is a formal review.

 Walkthrough: It is a review where the author leads the team

through a manual or simulated executed of the product using
pre-defined scenarios. Walkthrough is an informal review.
 Static Unit Testing
• The idea here is to examine source code in detail in a systematic
manner
• The objective of code review is to review the code, and not to
evaluate the author of the code
• Code review must be planned and managed in a professional manner
• The key to the success of code is to divide-and-conquer
• An examiner inspect small parts of the unit in isolation
 Nothing is overlooked
 Correctness of all examined parts of the module implies the
correctness of the whole module
 Static Unit Testing
(Formal Code Review)
• Step 1: Readiness –The author of the unit ensures that the unit
under test is ready for review. A unit is said to be ready if it
satisfies the following criteria –
 Completeness
 Minimal functionality
 Readability
 Complexity
 Requirements and design documents
Static Unit Testing
(Formal Code Review)

• Step 2: Preparation – Each reviewer develops the

following:
 List of questions
 Potential Change Request (CR)
 Suggested improvement opportunities
 Static Unit Testing
(Formal Code Review)

• Step 3: Examination – the examination process consists

of the following:
 The author makes a presentation
 The presenter reads the code
 The record keeper documents the CR
 Moderator ensures the review is on track
Static Unit Testing
(Formal Code Review)

• Step 4: Re-work – At the end of the meeting, the

record keeper produces a summary of the meeting
that includes the following information:
 Make the list of all the CRs
 Make a list of improvements
 Record the minutes of the meeting (optional)
 Author works on the CRs to fix the issue
Static Unit Testing
(Formal Code Review)
• Step 5: Validation
 CRs are independently
validated
• Step 6: Exit
 A summary report of the
meeting minutes is distributed
• A Change Request (CR) includes the
following details:
• Give a brief description of the issue
 Assign a priority level (major or minor)
to a CR
 Assign a person to follow it up
 Set a deadline for addressing a CR
 Steps in the
Formal Code Review process
Roles of the Formal Code Review

• Moderator: A review meeting is chaired by the moderator.

• Author: Person who has written the code to be reviewed.
• Presenter: A presenter is someone other than the author of the code.
• Record keeper: Should be different from the author & moderator. The
record keeper documents the problems found during the review process &
the follow-up actions suggested.
• Reviewers: These are the experts in the subject area of the code under
review.
• Observer: These are the people who want to learn about the code under
review.
 Static Unit Testing (Formal Code Review)

• Code Review Metrics: The following metrics can be collected

from a code review:
 The number of lines of code (LOC) reviewed per hour
 The number of CRs generated per thousand lines of code
(KLOC)
 The number of CRs generated per hour
 The total number of hours spend on code review process
 Code Review
• The code review methodology can be applied to review
other documents.
• Five different types of system documents are generated
by engineering department –
 Requirement
 Functional Specification
 High-level Design
 Low-level Design
 Code
Code Review
 Defect Prevention
• It is the best interest of the programmers in general to reduce the
number of CRs generated during code review
 Because CRs are indications of potential problems in the code,
and those problems must be resolved before different program
units are integrated
• Addressing CRs means spending more resources and potentially
delaying the project.
• Preventive measures can be taken during code development to
reduce the number of faults in a program.
 Defect Prevention

• It is essential to adopt the concept of defect

prevention during code development.
• In practice, defects are inadvertently introduced by
programmers. Those accidents can be reduced by
taking preventive measures.
• It is useful to develop a set of guidelines to construct
code for defect minimization. The programmers can
follow the guidelines to construct code.
Books

 Software Testing and Quality Assurance: Theory and Practice, by

Kshirasagar Naik, Priyadarshi Tripathy
References

1. Software Quality Engineering: Testing, Quality Assurance and

Quantifiable Improvement, by Jeff Tian
2. Software Quality Assurance: From Theory to Implementation, by
Daniel Galin
3. Software Testing and Continuous Quality Improvement, by William E.
Lewis
4. The Art of Software Testing, by Glenford J. Myers, Corey Sandler and
Tom Badgett