Object Oriented Testing Methods - Fault Based Testing

Object oriented system testing begins at different levels to uncover errors that may occur as classes collaborate with one another and subsystems communicate across architectural layers.
Actual object oriented testing begins with a series of tests designed to exercise class operations and check whether errors exists when a class collaborates with other classes.
Attributes and operations are encapsulated, testing operations outside of the class is unproductive. Encapsulation, an essential design concept, creates a minor obstacle during testing. Inheritance also leads to additional challenges for the test case designer. Multiple inheritance complicates testing further by increasing the number of contexts for which testing is required.
White box testing methods like basis path, loop testing or data flow techniques can help to ensure that every statement in an operation has been tested. Black box testing methods are also appropriate for object oriented systems as they are for systems developed using conventional software engineering methods.

FAULT BASED TESTING

The strategy for fault based testing is to hypothesize a set of plausible faults and then derive tests to prove each hypothesis. The objective of fault based testing within an object oriented system is to design tests that have a higher possibility of uncovering plausible errors. Test cases are designed to exercise the design or code and to determine whether faults exist. This approach is really no better than any random testing technique if faults in object oriented systems are implausible.

Three types of faults are encountered when integration testing looks for plausible faults in operation calls or message connections. These faults are:
- unexpected result.
- wrong operation/message used.
- incorrect invocation.
Integration testing applies to attributes as well as operations. Integration testing attempts to find errors in the client side and not the server.