OOSAD

Chapter Five

Object Oriented Testing

Introduction
• Testing is the process of finding differences between the expected
behavior specified by system models and the observed behavior of the
system

• The goal of testing is to design tests that detect defects in the system
and to reveal problems.

• The purpose of testing is not to demonstrate that the system is free

of errors. It is not possible to prove that a system is error free.

• The purpose of testing is to uncover differences between what the

system actually does and what the system should do

• In other words, the purpose of testing

Unity University is to try and break the system.
2
 Cont.

• To test a system effectively, a tester must have a detailed understanding

• There are four general stages of tests:

unit tests,
integration tests,
system tests, and
acceptance tests.

• Although each application system is different, most errors are found

during integration and system testing.

Unity University 3
Test Planning
• Testing starts with the development of a test plan, which defines a
series of tests that will be conducted.

• Because testing takes place throughout the development of an object-

oriented system, a test plan should be developed at the very
beginning of system development and continuously updated as the
system evolves.

• For example, the representation of a class evolves from a simplistic

CRC card to a set of classes that are implemented in a programming
language.

Unity University 4
 Cont.
• The test plan should address all products that are created during the
development of the system.

• Each individual test has a specific objective and describes a set of very
specific test cases to examine.

• Not all classes are likely to be finished at the same time, so the
programmer usually writes stubs for the unfinished classes to enable
the classes around them to be tested.

• A stub is a placeholder for a class that usually displays a simple test

message on the screen or returns some hardcoded value when it is
selected.

Unity University 5
Unit Testing
• Unit tests focus on a single unit—the class.

• In unit testing, the individual classes are tested.

• It is seen whether the class attributes are implemented as per design

and whether the methods and the interfaces are error-free.

• Using a behavioral state machine is a useful way to identify tests for a

class. Any class that has a behavioral state machine associated with it
has a potentially complex life cycle.

• There are two approaches to unit testing:

black-box testing and
white-box testing.
Unity University 6
 Cont.
Black-Box Testing

• Treats class as black box.

• Tester focuses on whether the class a meets the requirements stated in

the contracts specifications.

• We try various inputs and examine resulting output though which we

learn what the box does nor how conversion takes place
Test plan source: CRC Cards Class Diagrams
When to use: For normal unit testing

Unity University 7
 Cont.
White-Box Testing

• Looks inside the class to test its major elements.

• By looking inside the class to review the code itself, the tester may
discover errors or assumptions not immediately obvious to someone
treating the class as a black box.

Test plan source: Method Specifications

When to use: When complexity is high

Unity University 8
Integration Testing
• Integration tests assess whether a set of classes that must work together
do so without error.

• They ensure that the interfaces and linkages between different parts
of the system work properly.

• At this point, the classes have passed their individual unit tests, so the
focus now is on the flow of control among the classes and on the
data exchanged among them.

• The tester develops a test plan that has a series of tests, which, in turn,
have a test.

• Integration testing is often done by a set of programmers and/or

systems analysts. Unity University 9
 Cont.

• There are four approaches to integration testing:

user interface testing
use-case testing,
interaction testing, and
system interface testing

Unity University 10
 Cont.
User Interface Testing

• The tester tests each interface function.

• Testing is done by moving through each and every menu item in the
interface either in a top-down or bottom-up manner.
Test plan source: Interface Design
When to use: For normal integration testing

Unity University 11
 Cont.
Use-Case Testing

• The tester tests each use case.

• Testing is done by moving through each use case to ensure that they
work correctly.

• Usually combined with user interface testing because it does not

test all interfaces.
Test plan source: Use Cases
When to use: When the user interface is important

Unity University 12
Interaction Testing Cont.
• Tests each process in step-by-step fashion.

• The entire system begins as a set of stubs.

• Each class is added in turn and the results of the class compared to
correct result from the test data; when a class passes, the next class is
added and the test rerun.

• This is done for each package. Once each package has passed all
tests, then the process repeats integrating the packages.
Test plan source: class diagrams, sequence diagrams,
communication diagrams
When to use: When the system performs data processing
Unity University 13
 Cont.
System Interface Testing

• Tests the exchange of data with other systems.

• Because data transfers between systems are often automated and not
monitored directly by the users, it is critical to design tests to ensure
that they are being done correctly.

Test plan source: Use-Case diagrams

When to use: When the system exchanges data

Unity University 14
System Testing
• To ensure that all classes work together without error, systems analysts
usually conduct the system tests.

• System testing is similar to integration testing but is much broader in

scope.

• Whereas integration testing focuses on whether the classes work

together without error, system tests examine how well the system
meets both the functional and nonfunctional requirements, e.g.,
usability, documentation, performance, and security

Unity University 15
 Cont.
Requirements Testing

• Tests whether original business requirements are met.

• Ensures that changes made as a result of integration testing did not

create new errors.

• Testers often pretend to be uninformed users and perform improper

actions to ensure that the system is immune to invalid actions (e.g.,
adding blank records)
Test plan source: System Design, Unit tests, and Integration
Tests
When to use: For normal system testing
Unity University 16
 Cont.
Usability Testing

• Tests how convenient the system is to use.

• how well the user interface supports the use cases

• Often done by analyst with experience in how users think and in good
interface design
Test plan source: Interface design and use cases
When to use: When user interface is important

Unity University 17
 Cont.
Documentation Testing

• Tests the accuracy of the documentation

• Analysts spot check or check every item on every page in all

documentation to ensure that the documentation items and examples
work properly.
Test plan source: Help System, Procedures, tutorials
When to use: For normal system testing

Unity University 18
 Cont.
Performance Testing

• Examines the ability to perform under high loads

• High volumes of transactions are generated and given to the system

• Fall into two categories: stress tests(load test) and volume tests.

• The purpose of stress tests is to ensure that the system can handle a
certain number of simultaneous requests.

• The purpose of volume tests is to push the implementation so that it

may break when there is a large amount of data required to answer a
user request.
Test plan source: System proposal, Infrastructure design
Unity University 19
When to use: when the system is important
Security Testing Cont.
• Tests disaster recovery and unauthorized access

• Security testing is a complex task, usually done by an infrastructure analyst

assigned to the project. In extreme cases, a professional firm may be hired .

• It involves three primary areas:

• Authentication: deals with ensuring that the logged in user is who he or she
claims to be

• Authorization: deals with ensuring that the logged in user actually has the
authority to use the system(s) being accessed.

• Given that many system break-ins are a function of viruses, virus controls
also need to be enforced
Test plan source: Infrastructure design
Unity University 20
Acceptance Testing
• Acceptance testing is done primarily by the users with support from
the project team.

• The goal is to confirm that the system is complete, meets the business
needs that prompted the system to be developed, and is acceptable to
the users.

• Acceptance testing is done in two stages:

Alpha testing
Beta testing

Unity University 21
 Cont.

Alpha Testing
• Conducted by users to ensure that they accept the system

• Often repeats previous tests but are conducted by users themselves to ensure
that they accept the system.

• Users test the system using made-up data

Test plan source: System Tests

When to use: For normal acceptance testing

Unity University 22
 Cont.

Beta Testing
• Uses real data, not test data

• Users closely monitor system for errors or t useful improvement.

Test plan source: System requirements

When to use: When the system is important

Unity University 23
Testing and Object Orientation
• Most testing techniques have been developed to support non–object-
oriented development.

• Therefore, most of the testing approaches have had to be adapted to

object-oriented systems.

• The characteristics of object-oriented systems that affect testing the

most are encapsulation (and information hiding); polymorphism (and
dynamic binding); inheritance; and the use of patterns, class libraries,
frameworks, and components

Unity University 24
 Cont.

Encapsulation and Information Hiding

• The only way to know the effect that a business process has on a system is to
look at the state changes that take place in the system. But in object-oriented
systems, the instances of the classes hide the data behind a class boundary.
How is it possible then to see the impact of a business process?

• A second issue raised by encapsulation and information hiding is the

definition of a “unit” for unit testing. What is the unit to be tested? Is it the
package, class, or method? The answer is the class. This dramatically changes
the way unit testing is done.

Unity University 25
 Cont.

Encapsulation and Information Hiding

• A third issue raised is the impact on integration testing. In this case, objects
can be aggregated to form aggregate objects, or they can be grouped together
to form collaborations.

• Furthermore, they can be used in class libraries, frameworks, and components.

• Based on all of these different ways classes can be grouped together, how
does one effectively do integration testing?.

Unity University 26
 Cont.
Polymorphism and Dynamic Binding
• Affect both unit and integration testing.

• with polymorphism and dynamic binding, the same method can be

implemented in many different objects. Therefore, testing individual
implementations of methods makes no sense. Again, the unit that makes sense
to test is the class.

• Except for trivial cases, dynamic binding makes it impossible to know which
implementation is going to be executed until the system does it. Therefore,
integration testing becomes very challenging.

Unity University 27
 Cont.
Inheritance
• Through the use of inheritance, bugs can be propagated instantaneously from
a superclass to all its direct and indirect subclasses.

• However, the tests that are applicable to a superclass are also applicable to all
its subclasses.

• As usual, inheritance is a double-edged sword

Reuse
• On the surface, reuse should decrease the amount of testing required.

• However, each time a class is used in a different context, the class must be
tested again.

• Therefore, any time a class library, framework, or component is used, unit

testing and integration testing areUnityimportant
University 28