UNIT TESTING

1. Unit Test: Definition

• Unit is the smallest possible testable s/w component

• Unit in a typical procedure-oriented s/w system

– Performs a single cohesive function

– Can be compiled separately

– In a task in WBS

– Contains code that can fit on a single page/screen

Procedures & Classes/objects and Procedure sized reusable

functions methods components

– As the s/w component to be tested is small in size & simple in function, it is easier to
design, execute, record & analyze test results and easier to locate & repair defects.

• Unit testing is testing whether the smallest possible testable s/w component works as
specified in its specification.

2. Unit test : The need for preparation

• Goal of unit testing – to ensure that each individual s/w unit is functioning according to its
specification
Planned – designing tests to reveal defects like
• Good testing practice calls for unit tests
(Function description defects, algorithmic defects,
data defects, control logic & sequence defects)

Public – unit should be tested by an independent

tester. Results & defects should be stored in unit
history
• Unfortunately, in many cases unit test is performed informally by the unit developer, defects
found are private & not part of the history.
• To implement best practices, it is important to plan& allocate resources
o If defects are not caught properly, they may be shown in integration,
system/acceptance test where it will be costlier

Dr.S.Roselin Mary, HOD-CSE ANAND INSTITUTE OF HIGHER TECHNOLOGY UNIT IV

 o Worst case – during operation, if failure occurs, development organization repair the
s/w at the clients site.
• Tasks to be done for the preparation of unit test
1. Plan the general approach for unit testing
2. Design the test cases and test procedures
3. Define relationships between the tests
4. Prepare the auxiliary code necessary for unit test.

3. Unit test Planning:

A general unit test plan may be the component of the master test plan/stand alone plan.

Documents that provide inputs for the unit test plan are project plan, requirements,
specification and design documents,

IEEE standard for unit testing insists the following phases.

1. Describe Unit test approach and Risks

2. Identify Unit features to be tested
3. Add levels of detail to the plan

Phase 1: Describe unit test approach and risks

o Outlining the general approach

o Test planner
1. Identifies test risks
2. Describes techniques to be used for unit test case designing
3. Describes techniques to be used for data validation & recording of test results
4. Describes requirements for test harnesses & other s/w interfaces
5. Identifies completeness requirements, degree of coverage, stop rule
6. Estimates resources needed for unit test

Phase 2: Identify Unit features to be tested

o Need information from the unit specification & detailed design description
o Planner decides which features of each unit will be tested
o Features not covered by the tests should be mentioned and their risks should be
assessed
o Input output characteristics associated with each unit should be identified

Phase 3: Add levels of detail to the plan

o Planner – refines the plan – add details to the approach, resources & scheduling
portions of the test plan

Dr.S.Roselin Mary, HOD-CSE ANAND INSTITUTE OF HIGHER TECHNOLOGY UNIT IV

 o Unit availability & integration scheduling information should be included in revised
version of the test plan
o Include description of how test results will be recorded
o Test related documents & tools – described
4. Designing the Unit tests
• Specify i) test cases ii) test procedures
• Test case data should be tabularized –for the ease of use & reuse
• for OO test design, components of test case should be➔ ObjectId, TestcaseId, purpose & List of
test case steps
• test design specification → list of relevant states, messages, exceptions & interrupts
• developers/testers should describe the relationships between the tests
• test suites can be defined
• test case design at the unit level – use of black & white box test design strategies ➔ explain
5. Unit tests for classes
-Refer the notes given at the last
6. Test Harness: (auxiliary code developed to support testing of units & components is
called Test hareness.)
• in addition to developing test cases, supporting code must be developed to exercise each unit &
to connect it to outside world.
• As tester is considering a standalone function/procedure/class, code will be needed to call the
target unit and also able to represent modules that are called by the target unit
• Harness consists of
o Drivers that call the target code
o Stubs that represent modules it calls
• Development of drivers & stubs requires testing resources
• Drivers & stubs must be tested & reusable for the subsequent release of the s/w
• Drivers & stubs can be developed at several levels of functionality
E.g: options & combinations of options
For drivers
1. Call the target unit
2. Do 1, and pass i/p parameters from a table
3. Do 1,2 and display parameters
4. Do 1,2,3 and display results
For stubs
1. Display a message that it has been called by target unit
2. Do 1, and display any i/p parameters passed from target unit
3. Do 1,2 and pass back a result from a table
4. Do 1,2,3 and display result from table

Dr.S.Roselin Mary, HOD-CSE ANAND INSTITUTE OF HIGHER TECHNOLOGY UNIT IV

Drivers & stubs are➔ procedures/functions in procedural language.

➔ special classes in Object orientation.

Test hareness for individual classes will be more complex than those needed for individual procedures.

7. Running the Unit tests and Recording results:

➢ Unit test can begin when
• Units become available from developer
• Testcases are ready & reviewed
• Test hareness & other tools are available
➢ run the test
➢ record the results – use test log
➢ status of the test effort & summary of test results could be recorded in the following format.

➢ The tester must determine from the results whether the unit has passed/failed the test. If the
test is failed, the problem should be recorded in the Test Incident report.
➢ Deviations from the expected behavior should be recorded and described in detail. This gives
clues to locate defects
➢ During testing, tester may decide whether additional tests are required
➢ When a unit fails, reasons may be

Dr.S.Roselin Mary, HOD-CSE ANAND INSTITUTE OF HIGHER TECHNOLOGY UNIT IV

 o a fault in Test case specification
o a fault in Test Procedure specification
o a fault in test environment
o a fault in unit design
➢ The causes of failure should be recorded in Test summary report.
➢ When a unit has been completely tested and passes all of the required test, it is ready for
integration.
➢ In some situation, a Unit may be given a conditional acceptance for integration test.

5. Unit Testing a set of classes

• Classes are the building blocks for an entire OO system

• Class should be tested before it is published for use.

A. Reasons for testing the classes individually:

– A class is mainly for reuse. So, a residual defect in a class affect every instance of reuse.

– Many defects are introduced during the definition of a class.

• A delay in finding these defects, will affect wherever these classes are used.

• Fixing these defects should be updated wherever defects occurred

– A class may have different features. Clients may use different features of the class.
Unless the class is tested as a unit first, there may be features of a class that may never
get tested.

– A class is a combination of data and methods, the sync of data and methods should be
tested at the unit level. Otherwise it may lead to a confusion later.

– As inheritance concept is in OO system, each class should be tested at unit level.

B. Conventional methods that apply to testing classes:

– Boundary value analysis & equivalence partitioning → to test variables in a class

– Function coverage → to test methods in a class

Dr.S.Roselin Mary, HOD-CSE ANAND INSTITUTE OF HIGHER TECHNOLOGY UNIT IV

 – Condition coverage, branch coverage, code complexity → to test the logic in all
methods

– Stress testing → to test the multiple instances (objects) of classes by different users

– State based testing → For the messages that trigger the state transition

• Is every state reached atleast once?

• Is every generated message tested?

• Is every state trransition achieved atleast once?

• Are illegal state transitions tested?

C. Special considerations for testing classes

– To test an instantiated object, messages have to be passed to various methods.

– In what sequence does one pass the messages to the objects?

– Alpha – Omega Method is effective for the above.

– Principles/Objectives of Alpha – Omega Method:

• Test the object through its life cycle from its construction(birth) to
destruction(death).

• Test simple methods first and then test the complex functions.

• Test the methods from private through public methods. Private methods are
methods that are not visible outside the object/class.

• Send a message to every method atleast once. This ensures that every method
is tested atleast once.

– Steps of the Alpha- Omega Method:

• Test the constructor methods first. Each class may get constructed by multiple
constructor messages. All the constructor methods should be tested
individually.

• Test the get methods or accessor methods in order to ensure that the variables
in the class definition are accessible by the appropriate methods.

• Test the methods that modify the object variables. Test the methods that test
the contents of the variables, set/update the contents of variables, methods
that loop through various variables

Dr.S.Roselin Mary, HOD-CSE ANAND INSTITUTE OF HIGHER TECHNOLOGY UNIT IV

 • Check whether all the resources used by the object were destroyed, when the
object was destroyed.

– Encapsulation is meant to hide the details of class from the clients of the class

– The inside behavior of encapsulated part is less visible to the tester

– White box testing of classes with encapsulation becomes difficult

– A class can:-

• Inherit variables & methods from its parent class

• Redefine variables & methods from its parent class

• Define new variables & methods that are specific to it & not applicable to parent

• When a class is introduced for the first time, all variables & methods have to be tested fully.

• From then on whenever a class is derived from a parent class, the following need to be tested:-

✓ The changes made to the base class variables & methods & attributes

✓ New variables & methods that have been introduced in derived class

Testing all changes or new additions at the point of creation & selective re-testing of other unchanged
attributes is called incremental class testing.

• Two other forms of inheritance are:-

– Multiple inheritance: child class is derived from two parent classes

– Abstract class (a class that has a virtual method)

Dr.S.Roselin Mary, HOD-CSE ANAND INSTITUTE OF HIGHER TECHNOLOGY UNIT IV