1. Defensive Programming CNS 3370 Copyright 2003, Fresh Sources, Inc.

2. Agenda Invariants and Assertions Automated Unit Testing

3. Defensive Programming Prevention is better than cure Just as good design yields better product –Defending against errors cuts down on lengthy debugging sessions Good design should be evident in code –Because code is executable; comments aren’t –Key design checkpoints should be checked automatically

4. Invariants Conditions that do not vary –“Design mileposts” in your code Loop invariants –True at beginning of each loop iteration and after termination if all went well Class invariants –True before and after each method call Method invariants –Pre- and post conditions –Part of “Contract Programming” Plain old invariants

5. Loop Invariants A condition that is true at the beginning of each loop iteration and when the loop terminates Part of program correctness proofs –Mostly an academic exercise –Ensures correctness Often conceptual –Should be used more often! –Must be commented instead of tested at times Example: HiLo.cpp

6. Class Invariants All constructors should place their object in a valid state All methods should leave their object in a valid state –The method’s pre-condition and post-condition together should guarantee this –Better than just blind coding and testing! Example: Rational class: –gcd(num,den) == 1

7. Contract Programming Introduced by a Frenchman working in Switzerland living in California –Bertrand Meyer Methods are contracts with the user Users must meet pre-conditions of the method –What the method expects –Index in a certain range, for example Method guarantees certain post-conditions

8. Parties in Contracts Clients and Suppliers Clients must satisfy pre-conditions –They may benefit from post-conditions –But don’t have to Suppliers must satisfy post-conditions –They may assume the pre-conditions –But don’t have to This affects inheritance…

9. Contracts and Inheritance Pre-conditions are contravariant –can be weakened in derived classes Post-conditions are covariant –can be strengthened in derived classes “Require no more; Promise no less”

10. Plain Old Invariants Appear anywhere: void MyVector::push_back(int x) { if(nextSlot == capacity) grow(); assert(nextSlot < capacity); data[nextSlot++] = x; }

11. Enforcing Invariants Sometimes with assertions –For programmer errors that don’t depend on end user Only fail if you mess up –For loop and plain old invariants, class invariants, and pre-conditions of non-public member functions Sometimes with exceptions –For pre-conditions on public member functions Sometimes with testing –Post-conditions are usually a method’s output

12. Assertions Around since old C days assert( ) macro: –Calls abort( ) if its argument is false And prints the expression, file, and line number! –Defined in –Enabled by default –Can turn off with NDEBUG: #define NDEBUG #include

13. Just a Word About Testing A Unit Test: –Is what you, the developer do to “ensure" correctness –Class or module based –Should be automated Don’t inspect output text; write boolean expressions and let the computer do the inspecting Examples: –JUnit, CppUnit, XSLTUnit, NUnit –Our test.h