Good Programming
No description yet. This curated deck is ready for daily study.
Card preview (24)
Defensive Programming
• Specifications for functions • Modularize programs • Check conditions on input/outputs (assertions)
Testing/validation
• Compare input/output to specs • It’s not working! • How can I break my program?
Debugging
• Study events leading up to the error • Why is it not working? • How can I fix my program?
Set yourself up for testing/debugging
• design code to ease this part • break programs into modules that can be tested and debugged individually • document assumptions
Ready to test?
Ensure code runs - remove syntax errors - remove static semantic errors - Python Interpreter can usually find these Set of Expected results - and input set - for each input a corresponding output
Classes of tests
• Unit testing • Regression testing • Integrations testing
Unit testing
• validate each piece of the program - testing each function separately
Regression testing
• add test for bugs as you find them in a function - catch reintroduced errors that were previously fixed
Integration testing
• does overall program work? - tend to rush to do this
Testing methods
• Intuition • Random testing • Black Box Testing • Glass Box Testing
Intuition
Pick natural boundaries to the problem
Random testing
If no natural partitions • Probability that code is correct increases with more test • Better options with Black Box and Glass Box
Black Box Testing
Explore paths through specifications
Glass Box Testing
Explore paths through code
More about Black Box testing
• Designed without looking at the code • Avoid biases implementations • Testing can be reused Paths through specification • build test cases in different natural space partitions
Considerations for Black Box testing
• empty lists • singleton lists • large numbers • small numbers
More about Glass Box testing
• Use code directly to guide design of test cases - Called path-complete if every potential path through code is tested at least once
Drawback for Glass Box testing
• can go through loops arbitrary many times - missing paths
Guidelines for Glass Box testing
Branches - exercise all parts of a conditional for loops - loop not entered - body of loop executed exactly once - body of loop executed more than once while loops - same as for loops
Runtime bugs
• Overt • Covert • Persistent • Intermittent
Overt
• Has an obvious manifestation - Code crashes or runs forever
Covert
• Has no obvious manifestation - Code returns a value, which may be incorrect but hard to determine
Persistent
• Occurs every time code is run
Intermittent
• Only occurs some times - even if run on same input