1 / 24

Assert early and assert often

This article provides practical tips and benefits of using assertions in software development. It discusses various scenarios where assertions can be beneficial and provides examples and explanations of different assertion techniques. The article emphasizes the importance of early and frequent assertion usage and highlights their role in improving code quality.

rhamrick
Download Presentation

Assert early and assert often

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. Assert early and assert often Practical hints on effective asserting Tony Hoare Techfest February 2002

  2. Benefits of assertions today… • Test probes • Program documentation • Interface specification • Code optimisation • Defect tracking • Reduction of noise from analysis • Hardening of retail code

  3. … and more tomorrow • Accuracy of program analysis • Test case generation/prioritisation • Post-mortem dump-cracking • Concurrency safety • Validation of security • Programming language design

  4. Engineering test probes • Analogy: engine on a test bench • Instrumented at internal interfaces • To test tolerances continuously • And avoid test to destruction • Opportunity to improve quality by tightening the tolerances

  5. Macros #ifdef DEBUG #define CHECK(b,str) { if (b) { } else {report (str); assert (false)} } #else #define CHECK(b,str) #endif

  6. Explanations • CHECK( assertion, “reason why I think the assertion is true”) • Otherwise it’s easy to forget. • Helps both writer and reader. • Pinpoints risk of similar errors • Helps to avoid them in future

  7. Other variants • VSASSERT Visual Studio • MsoAssert Office • Debug.Assert C# • …

  8. Documentation • Protection for system against future changes if (a >= b){ .. a++ ; .. }; .. .. CHECK(a != b, ‘a has just been incremented to avoid equality’) ; x = c/(a - b)

  9. Assumptions • Used only during early test SIMPLIFYING_ASSUMPTION (strlen(input) < MAX_PATH, ‘’not yet checking for overflow’’) • Failure indicates test was irrelevant • Prohibited in ship code

  10. Compile-time • #define COMPILE_TIME_CHECK (b) extern dummy[(b)?1:-1] • Generates report at compile time • COMPILE_TIME_CHECK (sizeof(x)==sizeof(y), ‘addition undefined for arrays of different sizes)

  11. Invariants • True of every object … • …before and after every method call • bool invariant ( ) {…tests that list is circular…}

  12. Invariants • Integrity checking • Software audits • Post-mortem dump-cracking.

  13. Interface assertions • Useful to implementer and all users • Used again on each release • Reduce need to examine code • Aid the unit test of each module • Permit modular analysis and proof

  14. Preconditions void insert(node *n){ PRECONDITION ( n != NULL && invariant(), ‘don’t insert a non-existent object’); SIMPLIFYING-ASSUMPTION (find(n)== 0); .. .. ..

  15. Post-conditions .. .. POST_CONDITION ( find(n)&& invariant(), ‘the inserted object will be found in the list’) } • obligation on method writer to verify

  16. Optimisation switch (condition) { case 0: .. .. ; break; case 1: .. .. ;break; default: UNREACHABLE(‘condition is really a boolean’);} • Compiler emits less code

  17. Defect tracking • Office Watson keys defects by assertions • Integrates with RAID data base • Identifies bugs across builds/releases • Integral to the programming process

  18. PREFIX_ASSUME • Reduces PREFIX noise • pointer = find (something); PREFIX_ASSUME ( pointer != NULL, “see the insertion three lines back”); … pointer ->mumble = blat …

  19. Rugged code in retail • VSASSERT assertions are ignored • VsVerifyThrow … generate exception • VsVerify …user chooses

  20. Life of an assertion • Design discussions: record decisions • Project planning: interface contracts • Test planning: harness design • Test case selection: violate post-conditions • Coding: correctness concerns • Prototyping: simplifying assumptions

  21. … continued • In later release: detect regression • Defect tracking: fault classification • In retail: crash-proofing • Defect analysis: dump-cracking • Evolution of legacy: documentation

  22. Conclusion Assert early, assert often, and assert more strongly every time.

  23. Apologies to… ‘Vote early, vote often’ is the Politishun’s golden rule. Josh Billings American humorist, 1816-85.

  24. Acknowledgementsthoare@microsoft.com Rick Andrews, Chris Antos, Tom Ball, Pete Collins, Terry Crowley, Mike Daly, Robert Deline, John Douceur, Sean Edmison, Kirk Glerum, David Greenspoon, Yuri Gurevich, Martyn Lovell, Bertrand Meyer, Jon Pincus, Harry Robinson, Hannes Ruescher, Marc Shapiro, Kevin Schofield, Wolfram Schulte, David Schwartz, Amitabh Srivastava, David Stutz, James Tierney

More Related