1 / 13

Reliable Objects: Lightweight Testing for OO Languages

Reliable Objects: Lightweight Testing for OO Languages. David Mattingly. 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. Specifying behavior.

curran-horn
Download Presentation

Reliable Objects: Lightweight Testing for OO Languages

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. 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.

More Related