UNIT TESTING
MODULE: 2
Presented by:
Manju Mathews
CONCEPT OF UNIT TESTING
• Testing program units in isolation
• Program units - functions, procedures, or methods or even a class
• a piece of code, such as a function or method of class, that is invoked
from outside the unit and that can invoke other program units
• implements a well-defined function
• piece of code implementing a “low”-level function
CONCEPT OF UNIT TESTING
• Testing in isolation (Unit Testing )ensures:
• Errors found during testing can be attributed to a specific unit , can be easily
fixed
• No dependency on other units
• Verify that each distinct execution of a program unit produces the expected
result
• Ideally all possible distinct executions are to be considered during
unit testing
SCOPE OF UNIT TESTING
• A Programmer needs to test a unit as follows:
• Execute every line of code.
• Execute every predicate in the unit to evaluate them to true and false
separately
• Observe that the unit performs its intended function and ensure that it
contains no known errors
Unit testing
• Unit testing is performed by the programmer who writes the program unit
• Objective : programmer satisfied that the unit works as expected
• Idea is to push the quality concept down to the lowest level of the
organization and empower each programmer to be responsible for his own
quality
• Defects found during unit testing are internal to the software development
group
• Not reported up the personnel hierarchy to be counted in quality
measurement metrics
• Programmer completes unit testing , checks in the unit to the version
control system, only then unit used by other group members
Unit testing
• 2 phases
• Static Unit Testing : non-execution-based unit testing
• Dynamic Unit Testing : execution based
• Static Unit Testing :
• programmer does not execute the unit
• code is examined for all possible behaviors that might arise during run time
• code is validated against requirements of the unit by reviewing the code
• During the review process, issues are identified and resolved
• Eg Whether to use abort() or exit() to halt a pgm
• Static unit testing less expensive than dynamic unit testing
• Eg Code Review
Static Unit Testing
• Code reviewed by 2 techniques:
• Inspection: A step-by-step peer group review of a work product,
with each step checked against predetermined criteria
• Walkthrough: It is a review where the author leads the team through
a manual or simulated execution of the product using predefined
scenarios
• a systematic approach to examining source code in detail
• Goal is to assess the quality of the software
CODE REVIEW
• code review must be planned and managed in a professional manner
• Review code, avoid clash between programmer and reviewers
• There is a need for mutual respect, openness, trust, and sharing of
expertise in the group
• General guidelines for performing code review consists of six steps :
readiness, preparation, examination, rework, validation, and exit
• Input to readiness is criteria, the process produces two types of
documents, a change request (CR) and a report
Steps in Code Review Process
Steps in Code Review Process
• Step 1: Readiness: The author of the unit ensures that the unit under
test is ready for review: Criteria:
• Completeness: All the code relating to the unit to be reviewed must
be available
• Minimal Functionality: The code must compile and link, tested to
make sure basic functionalities
• Readability: Ensure code is highly readable
• proper formatting, using meaningful identifier names, straightforward use of
programming language constructs, and an appropriate level of abstraction
using function calls
Steps in Code Review Process
• Complexity: sufficiently complex
• number of conditional statements in the code, the number of input data
elements of the unit, the number of output data elements produced by the
unit, real-time processing of the code, and the number of other units with
which the code communicates
• Requirements and Design Documents : Latest approved version of
the low-level design specification and requirements documents
should be available:
• Ensures unit satisfies functionality and Design
Requirements Documents
Steps in Code Review Process: Readiness
• People in code review process informed two or three days before the
meeting
• given a copy of the work package for their perusal
• Reviews conducted in bursts of 1–2 hours
• The rate of code review is about 125 lines of code (in a high-level
language) per hour.
• involves a number of people with different roles
Different Roles involved in Code Review
Process
• Moderator: A review meeting chaired by the moderator
• trained individual, guides the pace of the review process
• selects the reviewers and schedules the review meetings
• from different team
• Author : written the code
• Presenter:
• reads the code beforehand to understand it
• presents the author’s code in the review meeting
• Recordkeeper: documents the problems found during the review process
and follow-up actions
• Reviewers: experts , 3-7 group size
• Observers: passive observers, want to learn code under review
Code Review Process: Preparation
• Step 2: Preparation : the reviewers read the code and understand its
organization and operation before the review meeting. Each reviewer
develops the following:
• List of Questions: ( based on table given)
• Potential CR: make a formal request to make a change
• Suggested Improvement Opportunities: how to fix problems
Code Review Checklist
Code Review Process: Examination
• Step 3: Examination - Activities
• The author makes a presentation of the procedural logic used in the code,
the paths denoting major computations, and the dependency of the unit
under review on other units
• The presenter reads the code line by line. The reviewers may raise
questions if the code is seen to have defects.
• The reviewers may make general suggestions on how to fix the defects
• The recordkeeper documents the change requests and the suggestions for
fixing the problems
• A CR 1. Give a brief description of the issue or action item. 2. Assign a
priority level (major or minor) to a CR. 3. Assign a person to follow up the
issue. 4. Set a deadline for addressing a CR.
Examination contd…
• The moderator ensures that the meeting remains focused on the
review process. Achieves objectives.
• At the end of the meeting, a decision is taken regarding whether or
not to call another meeting to further review the code.
• If the review process leads to extensive rework of the code or critical
issues are identified in the process, then another meeting is generally
convened. Otherwise, a second meeting is not scheduled, and the
author is given the responsibility of fixing the CRs.
Step 4: Rework
• Step 4: Rework: At the end of the meeting, the recordkeeper
produces a meeting summary
• A list of all the CRs, the dates by which those will be fixed, and the
names of the persons responsible for validating the CRs
• A list of improvement opportunities
• The minutes of the meeting (optional)
• A copy of the report is distributed to all the members of the review group.
After the meeting, the author works on the CRs to fix the problems. The
author documents the improvements made to the code in the CRs.
Step 5: Validation
• Step 5: Validation :
• The CRs are validated by the moderator or another person
• This involves checking the modified code as documented in the CRs
and ensuring that the suggested improvements have been
implemented correctly
• The revised and final version of the outcome of the review meeting is
distributed to all the group members
Step 6: Exit
• Every line of code in the unit has been inspected.
• If too many defects are found in a module, the module is once again
reviewed after corrections are applied by the author. (if more than 5% of
the total lines of code)
• The author and the reviewers reach a consensus that when corrections
have been applied the code will be potentially free of defects.
• All the CRs are documented and validated by the moderator . The author’s
follow-up actions are documented.
• A summary report of the meeting including the CRs is distributed to all the
members of the review group
CODE REVIEW METRICS
• ability of a reviewer to find defects in code by visual means
• code review is a testing strategy used to improve the quality of
products at an early stage
• Number of lines of code (LOC) reviewed per hour
• Number of CRs generated per thousand lines of code (KLOC)
• Number of CRs generated per hour
• Total number of CRs generated per project
• Total number of hours spent on code review per project