1 / 12

Adequate Testing in Object-Oriented Programming: The Antidecomposition Challenge

This document discusses the necessity of retesting software components when reused in different contexts, particularly focusing on the antidecomposition adequacy rule as posited by Weyuker. It highlights the importance of both program-based and specification-based testing, illustrating that adequate testing of a program does not guarantee that all components are adequately tested when context changes. Examples are provided to demonstrate the implications of class graph modifications and the challenges of maintaining testing integrity within object-oriented programming paradigms.

maxine
Télécharger la présentation

Adequate Testing in Object-Oriented Programming: The Antidecomposition Challenge

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OO Testing Problems Adequate Testing and OOP Perry/Kaiser

  2. Antidecomposition Adequacy • Reusing a piece of software in a new context requires retesting. Antidecomposition (AD) adequacy rule (Weyuker) • There exists a program P and a component Q of P such that T is adequate for P, T' is the set of vectors of values that variables can assume on entrance to Q for some t of T and T' is not adequate for Q. P Q

  3. Applicability • Program-based testing • Some part of Q is not reachable in P but is reachable in other contexts • Specification-based testing • The enclosing program P may not utilize all the functionality defined by the specification of Q

  4. Application to AP • Retesting after class graph change. Reusing a piece of software (e.g., a strategy) in a new context (a new class graph) requires retesting. Antidecomposition adequacy rule (Weyuker) • There exists a program P and a component Q of P such that T is adequate for P, T' is the set of vectors of values that variables can assume on entrance to Q for some t of T and T' is not adequate for Q.

  5. Application to AP • Adaptive program Q used in program P (determined by a class graph and Q). • If P is adequately tested, Q might not be adequately tested. P Q

  6. If class graph changes, it is necessary to re-test generated program. Whether program is hand-coded or generated, it needs to be tested. Comparison: AP versus OO during evolution

  7. DJ example ClassGraph cg = new ClassGraph();//*.java A a = new A(…); cg.traverse(a, new StrategyGraph (“A->B”, new MyVisitor());

  8. Application Antidecomposition: Retest inherited methods Class C { int v; void j(){v=0;}} class D extends C { void k(){v=1;}} Need to retest j in D!!!

  9. Other applications of testing rules • Encapsulated unit: syntactic separation • interface • implementation • Change in implementation only: what needs to be retested?

  10. Anticomposition rule • Adequately testing each individual program component does not necessarily suffice to adequately test the entire program. • Consider P and Q to be mutually recursive. P has the opportunity to modify the context seen by Q in a more complex way than could be done by stubs during testing of components in isolation

  11. Surprise • Intuition: Specification-based testing: limit testing only to modified unit. • Anticomposition: need to retest every dependent unit as well

  12. Test adequacy axioms • Antiextensionality: if two programs compute the same function

More Related