Download
reliable objects lightweight testing for oo languages n.
Skip this Video
Loading SlideShow in 5 Seconds..
Reliable Objects: Lightweight Testing for OO Languages PowerPoint Presentation
Download Presentation
Reliable Objects: Lightweight Testing for OO Languages

Reliable Objects: Lightweight Testing for OO Languages

128 Views Download Presentation
Download Presentation

Reliable Objects: Lightweight Testing for OO Languages

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Reliable Objects:Lightweight Testing for OO Languages David Mattingly

  2. Problems addressed • Based on waterfall model – not on iterative models. • No longer feasible to separate testing from specification, design, coding. • Not based upon inherent power of OO.

  3. Specifying behavior • Must know what each component should do in every situation • No formal specification language

  4. Design by Contract • Lightweight descriptions • Captures mutual obligations and benefits • Must specify every consistency condition • Boolean assertions

  5. Implementation • Implementations exist in Eiffel, Java, C++, Perl. • Eiffel only language to directly support design by contract. • All other languages rely on outside utilities.

  6. Java Implementation • Example from Pylon library (www.nenie.org/eiffel/pylon) • Source code with self-testable classes at www.iu-vannes.fr/docinfo/stclass

  7. Java Design by Contract • Contract Watchdogs • trace and assert

  8. Implementation 1 • Call inherited functions directly in code. • Another level of inheritance. • Calls inside methods can be forgotten about.

  9. Implementation 2 • Contract definition in comments • Preprocessor • iContract (www.reliable-systems.com/tools)

  10. Making self-testable classes • Define pre and post-conditions in comments. • Interface inheritance and Delegation. • Testing methods: testing unit & goal

  11. Validation & Verification • Compile with iContract & Java compiler. • Output details results of tests.

  12. Abstract Classes • Cannot be self-testable • Can define contracts • Implementing classes inherit contracts

  13. Mutation Testing • Determine how adequate our tests our. • Adequate Test set distinguishes the original program from mutants.