Test Notes

Myth #1

Myth:

• OO testing is unnecessary. OO promotes incremental development and reuse, so we have a more effective way to develop trustworthy classes.

 Reality:

• Human error is as likely as ever. We have to check class functionality and interactions between classes

Myth #2

Myth:

• Testing is a structured waterfall idea and isn’t consistent with incremental OO development

Reality:

• Tests can be designed and exercised at many points in the process
• Paradigm of “design a little, code a little” becomes “design a little, code a little, test a little”
• Extreme Programming (XP) promotes early testing

Myth #3

Myth:

• Testing is too expensive

Reality:

• Pay me now or pay me MUCH more later
• Failures in operational systems can cause severe secondary problems
• Proper testing is very cheap by comparison, even when done manually
• Efficient testing of large or complex systems needs some automated support

Myth #4

Myth:

• OO testing is the same as conventional software

Reality:

• Polymorphism, inheritance, encapsulation present opportunities for error

Myth #5

Myth:

• Conventional testing is useless for objects

Reality:

• There is a large body of knowledge about testing
• Basic testing techniques continue to apply with necessary changes
• If scope of testing is small, ie classes and collaborations
• Testing techniques are very OO specific
• As scope of testing gets larger
• Testing techniques become more traditional

Myth #6

Myth:

• Inheritance means never having to say you are sorry
• Specializing from a trusted superclass means the inherited part of subclasses will also be correct
• We don’t need to retest inherited features

Reality:

• Subclasses create new ways to misuse inherited features
• Different test cases are needed for each subclass

Myth #7

Myth:

• Reuse means never having to say you are sorry
• Reusing trusted class means behavior of server object is trustworthy and doesn’t need to be tested

Reality:

• Nothing prevents a new client class from using the server object incorrectly
• All client class use of a server needs to be exercised

Myth #8

Myth:

• Black box testing is sufficient
• Designing test cases using class interface and specification assures the class is fully exercised
• White box testing violates encapsulation

Reality:

• Studies show black-box test suites typically only exercise 1/3 to 1/2 of the statements (let alone paths or states)
• Typically miss abnormal paths, exception and error handling