International Journal of Computer Applications (0975 – 8887)

Volume 42– No.8, March 2012

Testing Object-Oriented Software Systems: A Survey of

Steps and Challenges

Clarence J M N Ganesan Anupam Ghosh Nirupam Ghosh

Tauro Director (MCA) Christ University Christ University
Christ University RICM, Bangalore Bangalore, India Bangalore, India
Bangalore, India

ABSTRACT reliability and at the same time it is necessary to realize

Object-Oriented programming is a combination of different these benefits by uncovering as many programming errors as
levels consists of abstraction, class level cluster level and possible.
system level. In this article, we are going to discuss about the 3. WHAT TESTING IS AND ISN’T
different testing aspects for object oriented programs. Idea is Testing comprises the efforts to find defects. Testing does
to test different testing aspects of Object-oriented Software not include efforts associated with tracking down bugs and
Systems. The challenge is to cover testing with minimum fixing them. In other words, testing does not include the
effort to get maximum output. debugging or repair of bugs. Testing is a procedure of
finding faults, defects in the software. While debugging is to
Keywords rectify the faults, defects find during testing in the software.
Object-oriented software system, Unit-testing, Model based
testing, integration testing, system testing, test automation. 4. PROBLEM AND CHALLENGES
The object-oriented paradigm has set of testing and
1. INRODUCTION maintenance problems. The inheritance, aggregation and
Previously computer program was nothing but just a list of association relationships among the object classes make an
commands called functions where all data getting stored in OO program difficult to test. The encapsulation and
one single location which creates problem in testing the information hiding features result in chains of member
program properly. function invocations that often involve objects of more than
one class. The problems for software testing are:
Object-oriented testing and traditional testing are similar in
few aspects. Like we use unit testing, we perform integration 1. It is difficult to understand the code and prepare the test
testing to make sure all subsystems work correctly, we cases.
perform system testing to make sure software meets the 2. It is not cost-effective to construct test stubs for member
specified requirements. functions since most of them consist of one to two
statements. Rather, one would just use them provided
Object-oriented programming language has features like that they have been tested.
inheritance, polymorphism which is completely new and
3. It is necessary to determine and limit the required
brought technical challenges for tester while testing. This
regression tests when a function or a class is changed.
paper will tell how to test encapsulation, polymorphism
testing along with Unit-testing, Model based testing, 4. It requires a fresh look into the traditional coverage
integration testing. criteria and to extend them to include not just coverage
of individual functions, but also invocation sequence,
object stated and state sequences, and data definition
2. NEED OF TESTING and use path across functions and objects.[18]
Testing is a merry-go-round process which includes a good
amount of time along with cost, for all. But the reality is
quite opposite, without testing it is not possible to deliver 5. OO TESTING
projects successfully, as during software development, The fundamental unit of object-oriented program is class
developers make many mistakes throughout the different testing. The code for a class can be tested effectively by
phase of development and testing helps in correcting those review or by executing test cases. [1] For each class, decision
mistakes. In other way, testing encompasses all phases of is taken whether to test it independently as a unit or in some
development-in every phase; the work products of that phase way as a component of a larger part of the system. Initially
are tested. So in every phase of development there is testing we want to make sure that the requirements set forth in the
activity. For example, in the requirement engineering stage, specification are meeting exactly by the code for a class. The
the SRS (System Requirement Specification ) document is amount of attention given to testing a class to make sure that
written and tested to check whether it captures all the user it does nothing more than what it is specified for depends on
requirements or not. The same is applicable for object the risk associated with the class supplying extra behaviors.
oriented testing as object-oriented programming increases Any incomplete coverage of code after a wide range of test
software reusability, extensibility, interoperability, and cases have been run against the class could be an indicator

16
 International Journal of Computer Applications (0975 – 8887)
Volume 42– No.8, March 2012

that the class contains extra, undocumented behaviors. Or it change and therefore generally minimizes the amount of
could merely suggest that the implementation must be tested regression testing required at the UNIT level.
using more test cases.
The decisions are based on following factors:
 The role of the class in the system, especially the degree
of risk associated with it.

CLASS A CLASS C
The complexity of the class measured in terms of the
number of states, operations, and associations with other METHOD METHOD
classes.
 The amount of effort associated with developing a test
driver for the class.
USES
A test driver that creates instances of the class and sets up a USES
suitable environment around those instances to run a test case
is generally used to test Classes. The driver sends one or
more messages to an instance as specified by a test case, then
checks the outcome of those messages based on a reply CLASS B
value, changes to the instance, and/or one or more of the
parameters to the message. METHOD

OBJECT CLASS A Figure2. Encapsulation

E
METHOD 1 The order of unit testing can save a lot of time and effort.
METHOD
For example, using the dependencies shown in Figure2, if A
D is tested first, we require a stub for B, if B is then tested, we
METHOD 2 require a stub for C. If the testing order is reversed, C, B, A,
then the tester wouldn‘t have to create any stubs, he/she
METHOD could simply use the actual class, as a stub. [15]

B
C 5.2 Polymorphism
In the object oriented paradigm, it is possible to define a
METHOD single generic interface for multiple methods with the same
METHOD name that perform the same or similar operations. This helps
in reducing the complexity by using or reusing the same
interface to specify a general class of action.
Figure1. Object Class
As an example, a method used to draw graphics. If three
dimensions are passed, the method draw creates a triangle, if
Figure1 illustrates an example of an Object Class ―A‖ which
four dimensions a rectangle, five pentagons and so on. In
has two methods. This Object Class has a dependency
this case there are three different methods with the same
association with all other Classes as shown. If a change was
name but they accept different amounts of variables in the
made to the unit ―Object Class A‖ (METHOD 2), in theory
method call. Generally the selection of the variant is
all test cases involving the unit should be rerun, at all levels.
determined at run-time (dynamic binding) by the compiler
The dependency diagrams required for testing are less
based on, for example, the type or number of arguments
complex and association is easier to manage.
passed.
Few questions arise that need to be considered before testing:
5.1 Encapsulation 1. Do we only need to one variant?
In object oriented programming, all the operations that are 2. Do we test all variants?
performed on some data are modeled and stored within a
3. If all, do we need to test all at all levels?
single structure called a class. The behavior and interface
There isn‘t one set answer for these questions. The answers
(which is defined by the class' public methods) of a class are
to these questions will depend on the testers, the companies
defined by the methods that operate on its instance data. In a
policies etc. In a perfect world we would test everything.
conventional paradigm, the modeling of these two aspects is
However, in reality it is generally impossible to test
done separately. Encapsulation is about risk management,
everything in large scale projects.
reducing our maintenance burden, and limiting our exposure
The same test cases (Driver and Stubs) could be used to test
to vulnerabilities —especially those caused by
each variant at the UNIT level (test reuse). Also because of
bypassed/forgotten sanity checks or initialization procedures,
software reuse, it may not be necessary to test all the variants
or various issues that may arise due to the simple fact of the
at the INTEGRATION level if all are fully tested at the
code changing in different ways over time. Technically,
UNIT level. Whether each variant will be tested at the
encapsulation is hiding internal details behind an opaque
system level would depend on the requirements
barrier so as to force external entities to interact through
specification.
publicly available access points. It makes us consider exactly
how access is restricted. It also makes us consider what
exactly a detail that needs to be protected is, and what 5.3 Inheritence
exactly should be exposed to the outside world. Inheritance does not introduce new classes of faults, but it
Encapsulation minimizes the ripple effect of making a provides an opportunity for optimization by re-using test

17
 International Journal of Computer Applications (0975 – 8887)
Volume 42– No.8, March 2012

executions. [1] During analysis and design, inheritance 3. Redefined- In this case unit testing must be performed
relationships between classes can be recognized in the again since the structure of the inherited attribute has
following two general ways: been changed. Integration testing is conducted if the
attributes are used at that level in a scenario.
1. As a specialization of some class that has already been
4. Virtual Completed. Unit testing must be performed, and
identified
integration testing if used at that level of inheritance.
5. Virtual not completed- No testing is required.[15]
2. As a generalization of one or more classes that have
already been identified[15] 6. MODEL BASED TESTING
With increasing complexity of software program, it is
Inheritance relationships can be identified at just about any essential that people involve in design and development of
time during an iterative, incremental development effort. In software should communicate closely. Uniform Modeling
particular, the specialization relationship can be applied even Language (UML) gives us a standard way to create a
fairly late in an effort without a large impact on most other system‘s blueprint, covering business process and system
program components. This flexibility is one of the big classes and also concrete things like classes written in a
advantages to using inheritance and one of the strengths of specific programming language, database schema and
object-oriented technologies. reusable components. The use case model is a model design
Implementing classes is more straightforward when done based on the user‘s understanding/view of the system.
from the top of the hierarchy down. In the same way, testing The modeling diagrams used in UML:
classes in an inheritance hierarchy is generally more 1. Use case diagrams: The use case model captures the
straightforward when approached from the top down. In requirements of a system. Use cases are a means of
testing first at the top of a hierarchy, we can address the communicating with users and other stakeholders what
common interface and code and then the test driver code for the system is intended to do.
each subclass. Implementing inheritance hierarchies from the 2. Class diagrams: Class diagrams depict a static view of
bottom up can require significant refactoring of common the model, or part of the model, describing what
code into a new super class. behavior and attribute it has rather than detailing the
The chances of dealing with different inheritance structures process for achieving operations. Class diagrams are
and the added possibility of potentially dealing with multiple most useful in illustrating relationships between classes
forms of inheritance can add another level of complexity to and interfaces.
the testing process. [15] 3. Object diagrams: It is a special case of a class diagram.
Object diagrams use a subset of the elements of a class
These issues raise a number of questions: diagram in order to emphasize the relationship between
1. Do we completely test all BASE classes and their instances of classes at some point in time. They are
subclasses and at what levels should we test? useful in understanding class diagrams. They don‘t
2. Do we completely test all BASE classes and only the show anything architecturally different to class
changes or modifications in the subclasses, and if so at diagrams, but reflect multiplicity and roles.
which levels? 4. Sequence diagrams: A sequence diagram is a form of
3. In which order do we test the hierarchy, top down or interaction diagram which shows objects as lifelines
bottom up? running down the page, with their interactions over time
To answer number 3 first, the generally accepted practice represented as messages drawn as arrows from the
is to test top down, starting with. The levels to test at (unit, source lifeline to the target lifeline.
integration) are discussed in Table 1. 5. Collaboration diagrams: It describes interaction among
classes and associations. These interactions are modeled
Scenario Unit Integration as exchanges of message between classes through their
None X? association.
New X X? 6. State Machine diagrams: A state machine diagram
Redefined X X? models the behavior of a single object, specifying the
Virtual Completed X X? sequence of events that an object goes through during
Virtual not Completed its lifetime in response to events.
7. Activity diagrams: An activity diagram is used to
Table1. Inherited Testing display the sequence of activities. Activity diagrams
show the workflow from a start point to the finish point
The Table1 summarizes the recommended testing at the unit detailing the many decision paths that exist in the
and integration level for each method of inheritance. progression of events contained in the activity.
1. None- There is no need to perform unit testing if this 8. Component diagrams: Component diagrams illustrate
was done at the BASE class level. However there may the pieces of software, embedded controllers, etc., that
be a requirement to perform integration testing if the will make up a system. A component diagram has a
inherited attributes (methods and /or data) are used in a higher level of abstraction than a Class Diagram -
new scenario. usually a component is implemented by one or more
2. New- In this case the new attributes would need to be classes (or objects) at runtime.
tested at the unit level, since this is the first level at 9. Deployment diagrams: A deployment diagram models
which these attributes are introduced. They would be the run-time architecture of a system. It shows the
integration tested only if there are used by another class configuration of the hardware elements (nodes) and
in a scenario. shows how software elements and artifacts are mapped
onto those nodes.

18
 International Journal of Computer Applications (0975 – 8887)
Volume 42– No.8, March 2012

The vast majority of the work examining model based testing A test model is needed to support the definition of software
of OO systems focuses on the use of either class or state integration test strategies. [7]


diagrams. Class diagrams provide information about the Typical test models:


public interface of classes, method signatures, and important Control flow graph


relationships between classes. State diagrams provide Object-oriented class diagram
information about the behavior of a class (or the BASE class

Scenario-based model
and working our way down. This enables a tester to reuse

Component-based integration model
test cases, and potentially test results in certain situations set Architecture-based integration model
of classes.) .When Unit testing is completed then only we can
There are many phases in the testing process, including unit, perform Integration testing.
function, system, regression, and solution testing. The One of the biggest problems in integration testing is to
following table illustrates the differences between these determine how long to spend to test this phase as it takes
phases, as well as the potential UML diagram for use in the almost the whole testing phase.
phase. [17] Driver and Stub- Driver are programs which simulate the
behaviors of software components [2] (or modules) that are
Test type Coverage Fault UML the control modules of a under test module. Stubs are
Criteria Model Diagram programs which simulate the behaviors of software
components (or modules) that are the dependent modules of
Unit Code correctness, class and a under test module.
error state
handling diagram
pre / post
conditions, Driver Tested Stub
invariant Unit
Function Functional functional interaction
and API and class Figure3. Driver and Stub
behavior, diagrams
integration Strategies of Integration testing for object-oriented
issues software:-
System Operational workload, use case, 1. On Top Down testing process the main control module
Scenarios contention, activity, is used
synchron. , and as a test driver, and the stubs are substituted for all
recovery interaction modules directly subordinate to the main control
diagrams module, the subordinate stubs are replaced one at a time
Regression Functional Unexpected interaction with actual modules. The tests are conducted as each
behavior and class module is integrated. On completion of each set of tests,
from new / diagrams another stub is replaced with the real module.
changed A Top Down approach is obviously a White Box method as
function in depth knowledge of lower layers of the programs
functionality is required for the generation of the stub files.
Solution Inter-System Interop. use case
communication Problems and 2. Bottom UP Testing works in reverse of really Top
deployment Down testing. In this process the low-level modules are
diagrams combined into clusters that perform a specific software
sub-function. The driver is written to coordinate test
Table2. Diagram use in different testing phases case input and output. The test cluster is tested. Drivers
are removed and clusters are combined moving upward
The problem lies with UML is that during testing process it in the program structure. The advantages with this are
is not decided that which diagrams might be useful in various that once a layer has been completely tested, it‘s less
phases. Some issues need to be taken care before effectively likely that any Bug found has occurred in that layer.
applied UML in testing process. One issue is that it is Some other integration testing strategies are:
tempting to think that the models which are derived during
1. Execution based integration test – Tracing the execution
design and implementation can be used by tester as well. But
of an interaction. This testing strategy finds control
this is not feasible reason
flows that cannot be executed.
1. The model that derived from development process lack
details in features need to develop test cases. 2. Value based integration test – Executes the interaction
2. Tester gain valuable insight by building or modifying between components with certain values. This testing
the models in the testing process. corresponds to the traditional boundary value, input
validation and syntax testing. This testing strategy finds
7. INTEGRATION TESTING errors like passing of illegal parameters and
Software test strategy provides the basic strategy and interpretation problems of parameters.
guidelines to test engineers to perform software testing 3. Function based integration testing – Tests the correct
activities in a rational way. Software integration strategy provision of functionality through the component‘s
usually refers to an integration sequence (or order) to collaboration. This testing strategy focuses on detecting
integrate different parts (or components) together. mismatches between the interpretations of the
interaction between components.

19
 International Journal of Computer Applications (0975 – 8887)
Volume 42– No.8, March 2012

8. SYSTEM TESTING the test since only an automated test can cover the code in
The last phase of testing is System testing which comes just combination. In testing object-oriented systems, the test is
before the product is delivered to customer. This level of moved up to a higher level of abstraction, where test
testing ensures that the program matches the final automation is absolutely necessary.
specification that was drawn at beginning of the project. 12. ACKNOWLEDGMENT
[9]The most important thing in this phase is that it not We are heartily thankful to Prof. Jebrial, Prof. Joy Paulose,
concerned on how system works rather it is more concerned whose encouragement, guidance and support enabled us to
with the result produced. For this reason, system testing is
develop an understanding of the subject.
considered to be ‗Black Box testing‘. System Testing should
take place in the setup which is accurately reacts like the
system in which the product will be deployed. By this way 13. REFERENCES
any error occur can be easily caught and fixed before final [1] Mauro Pezz`e, Michal Young,‖ Testing Object Oriented
product release. Software‖, Proceedings of the 26th International
It seems that system tests for object oriented systems would Conference on Software Engineering (ICSE‘04), IEEE,
be no different to system tests for non-object oriented 2004
systems. Specifications for object oriented software can be [2] Priti Bansal, Sangeeta Sabharwal, and Pameeta Sidhu,
very different from non-object oriented software. For ―An Investigation of Strategies for Finding TestOrder
example, object-oriented systems can be modeled in UML During Integration Testing of Object Oriented
and use `Use Case' and `Class' diagrams. These diagrams are Applications‖, International Conference on Methods
then used to produce the test cases. and Models in Computer Science, IEEE, 2009
[3] Suganya G,Neduncheliyan S,‖A Study of Object
9. REGRESSION TESTING Oriented testing techniques: Survey and
Regression testing is performed similar to traditional systems challenges‖,IEEE Conferences,2010
to make sure previous functionality still works after new [4] John D. McGregor and David A. Sykes, ‖A Practical
functionality is added. [3] On changing a class which has Guide To Testing Object –Oriented Software‖Mar,
been tested previously implies that the unit tests should be 2001.
rerun. The test scenario may have to be adapted based on the [5] Perry D., Kaiser G.: ―Adequate Testing and Object–
changes done to support proper testing. In addition, the oriented Programming‖, Journal of 00-Programming,
integration test should be redone for that suite of classes. Vol. 2, No. 5,Jan. 1990,
10. TEST AUTOMATION [6] Gareth Thomas, ‖Object Orientated Integration
Not but the least automated testing always play vital role in Testing‖, December 14, 2006;
delivering product with good quality at proper time. Test [7] Jerry Gao Ph.D., ―Software Integration Testing‖, Jan
automation is software that automates any aspect of testing 1999
of an application system with a capability to generate test [8] Jilles van Gurp, ‖Object Oriented testing‖, December
inputs and expected results. It reduces the repetitive works 9,1998
that we do manually and also provide us the result as ‗pass‘ [9] Dafydd Vaughan, ―System Testing with Object-
or ‗fail‘. Oriented Programs‖, Jan 12,2007
The appropriate extent of automated testing depends on our [10] Binder, R. ―Testing Object-Oriented Systems. Models,
testing goals, budget, software process, kind of application Patterns, and Tools‖, Addison-Wesley, 1999.
under development, and particulars of the development and [11] Myers, G. ―The Art of Software Testing, John Wiley &
target environment. Sons‖, New York, 1979.
Automated tests ensure a low defect rate and continuous [12] Jilles van Gurp, ―Object Oriented Testing Report‖, 1998
progress, whereas manual tests would very rapidly lead to [13] Grady Booch, Ivar Jacobson and James
exhausted testers. To summarize the characteristics of tests Rumbaugh,‖The Unified Software Development
―,Process.1999

we are aiming at: [19]
Tests run the system – in contrast to static analyses. GradyBooch, RobertA.Maksimchuk , MichaelW.Engel,

[14]
Tests are automatic to prevent project members to get BobbiJ.Young, Jim Conallen, Kelli A. Houston,
bored with tests (or alternatively to prevent a system ―Object-Oriented Analysis and Design with
that isn‘t tested enough) Applications (3rd Edition)‖, 2007
 Automated tests build the test data, run the test and [15] Maj Nicko Petchiny, ‖Object Oriented Testing‖,April
1998

examine the result automatically.
Success resp. failures of the test are automatically [16] Jitendra S. Kushwah, Mahendra S. Yadav, Testing for
Object Oriented Software‖ Indian Journal of Computer

observed during the test run.
A test suite also defines a system that is running Science and Engineering(IJCSE),Feb 2001
together with the tested production system. The purpose [17] Clay E.Williams, ‖Software Testing and the UML‖,
of this extended system is to run the tests in an International Symposium on Software Reliability
Engineering(ISSRE99),Bocs,Baton,1999

automated form.
[18] D.Kung, J.Gao, P.Hsia, F.Wen,‖ Change Impact
A test is exemplar. A test uses particular values for the
Identification in Object Oriented Software

input data, the test data.
Maintenance‖Software maintenance,Proceeding,
A test is repeatable and determined. For the same setup
International Conference,IEEE,1994
the same results are produced. [19]
[19] Bernhard Rumpe,‖ Model-based Testing of Object-
11. CONCLUSION Oriented Systems‖, International Symposium, FMCO
The conclusion of this short expose is that it throws some 2002
light on different testing aspects of object-oriented software
system. And to full fill the challenge ‗to cover testing with
minimum effort to get maximum output‘, we need automate

20