Good Programming

Question 1

Defensive Programming

Answer 1

• Specifications for functions
• Modularize programs
• Check conditions on input/outputs (assertions)

Question 2

Testing/validation

Answer 2

• Compare input/output to specs
• It’s not working!
• How can I break my program?

Question 3

Debugging

Answer 3

• Study events leading up to the error
• Why is it not working?
• How can I fix my program?

Question 4

Set yourself up for testing/debugging

Answer 4

• design code to ease this part
• break programs into modules that can be tested and debugged individually
• document assumptions

Question 5

Ready to test?

Answer 5

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

Question 6

Classes of tests

Answer 6

• Unit testing
• Regression testing
• Integrations testing

Question 7

Unit testing

Answer 7

• validate each piece of the program

- testing each function separately

Question 8

Regression testing

Answer 8

• add test for bugs as you find them in a function

- catch reintroduced errors that were previously fixed

Question 9

Integration testing

Answer 9

• does overall program work?

- tend to rush to do this

Question 10

Testing methods

Answer 10

• Intuition
• Random testing
• Black Box Testing
• Glass Box Testing

Question 11

Intuition

Answer 11

Pick natural boundaries to the problem

Question 12

Random testing

Answer 12

If no natural partitions

• Probability that code is correct increases with more test
• Better options with Black Box and Glass Box

Question 13

Black Box Testing

Answer 13

Explore paths through specifications

Question 14

Glass Box Testing

Answer 14

Explore paths through code

Question 15

More about Black Box testing

Answer 15

• Designed without looking at the code
• Avoid biases implementations
• Testing can be reused
  Paths through specification
• build test cases in different natural space partitions

Question 16

Considerations for Black Box testing

Answer 16

• empty lists
• singleton lists
• large numbers
• small numbers

Question 17

More about Glass Box testing

Answer 17

• Use code directly to guide design of test cases

- Called path-complete if every potential path through code is tested at least once

Question 18

Drawback for Glass Box testing

Answer 18

• can go through loops arbitrary many times

- missing paths

Question 19

Guidelines for Glass Box testing

Answer 19

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

Question 20

Runtime bugs

Answer 20

• Overt
• Covert
• Persistent
• Intermittent

Question 21

Overt

Answer 21

• Has an obvious manifestation

- Code crashes or runs forever

Question 22

Covert

Answer 22

• Has no obvious manifestation

- Code returns a value, which may be incorrect but hard to determine

Question 23

Persistent

Answer 23

• Occurs every time code is run

Question 24

Intermittent

Answer 24

• Only occurs some times

- even if run on same input

Question 25

Overt and Persistent

Answer 25

- Obvious to detect | - Use defensive programming to try to ensure that if error is made, bug will fall into this category

Question 26

Overt and Intermittent

Answer 26

- More frustrating - Can be harder to debug - If condition that prompt bug can be reproduced -> can be handled

Question 27

Covert

Answer 27

- Highly dangerous | - users may not realize answers are incorrect until code has been run for a long period

Question 28

Debugging Tools

Answer 28

- Built in the IDE or code editor - Python Tutor - print statement - use your brain -> be systematic

Question 29

Print statements

Answer 29

- Test hypothesis | - Bisection method

Question 30

When to Print

Answer 30

- Enter function - Parameter - Function result

Question 31

Print using Bisection method

Answer 31

- Put print halfway in code | - Decide where bug may be depending on value

Question 32

Logic errors

Answer 32

- Think before writing new code - Draw picture - take a break - Explain the code to (someone else or a rubber duck)

Question 33

Debugging steps

Answer 33

- Study program code | - Scientific method

Question 34

Debugging using study method

Answer 34

- how did I get the unexpected result - dont' ask what is wrong - is it part of a family

Question 35

Debugging using scientific method

Answer 35

- study available data - form hypothesis - repeatable experiments - pick simplest input to test with

Question 36

Testing does

Answer 36

- Write a function - Test the function, debug the function - Write a function - Test the function, debug the function - *** Do integration testing ***

Question 37

Debugging does

Answer 37

- Backup code - Change code - Write down potential bug in a comment - Test code - Compare new and old versions

Question 38

Debugging skills

Answer 38

``` Treat as a search problem Looking for explanation for incorrect behavior - Study available data - Form hypothesis - Design and run a repeatable experiment - Keep record of experiments performed ```

Question 39

Debugging as search

Answer 39

- narrow down space of possible source of error - design experiments that expose intermediate stages of computation - use print statements - use results to further narrow search - binary search is a powerful tool

Question 40

Pragmatic hints for debugging

Answer 40

- look for usual suspects - ask why the code is doing what it is - the bug is probably not where you think it is - don't believe the documentation - take a break

Question 41

Exceptions

Answer 41

When a procedure execution hits an unexpected conditions

Question 42

IndexError

Answer 42

Trying to access beyond lists limits

Question 43

TypeError

Answer 43

Trying to convert an inappropriate type | Mixing data types without coercion

Question 44

NameError

Answer 44

Referencing a non-existing variable

Question 45

ZeroDivisionError

Answer 45

Trying to divide with 0

Question 46

ValueError

Answer 46

Operand type okay, but value is illegal

Question 47

IOError

Answer 47

IO system reports malfunction (eg. file not found)

Question 48

AttributeError

Answer 48

Local or global name not found

Question 49

What to do with Exceptions

Answer 49

- Fail silently -> bad idea! - Return an "error" value -> what value to choose, complicates code - Stop execution, signal error condition -> raise an exception

Question 50

Dealing with exceptions

Answer 50

- exceptions raised by any statement of try | - handled by the except and execution continues after the except statement

Question 51

Handling specific exceptions

Answer 51

Have separate except clauses to deal with particular type of exception

Question 52

Other exceptions

Answer 52

- else -> is executed when execution of try body completes with no exceptions - finally -> always executed after: try, else and except clauses. - finally is executed even if they raised another error or executed a break, continue or return - finally is useful for clean-up code that should be run no matter what else happened

Question 53

Exceptions as control flow

Answer 53

- Raise an exception when unable to produce a result consistent with functions specification

Question 54

Assertions

Answer 54

- Use assert statement to raise an AssertaionError | - An example of good defensive programming

Question 55

Assertions as defensive programming

Answer 55

- Don't allow a programmer to control response from to unexpected conditions - Ensure the execution halts - Typically used to check inputs to functions - Can be used to check outputs of a function - Can make it easier to locate a source of a bug

Question 56

Where to use assertions

Answer 56

- Goal to spot bugs - Supplement to testing - Raise exceptions if bad data is inputted - Check types - Check that in-variants on data structures are met - Check constraints on return value - Check for violations of constraints on procedure (e.g. no duplicates in a list)