Topic 8

Testing, Debugging and Exception

Handling
Last Topic

§ The concept of file

§ Read and write text files
§ Read and write CSV files
§ Get operating system information
§ Access the underlying file system

www.codemasterinstitute.com
2
This Topic

§ Testing
§ Debugging
§ Catch exceptions
§ Raise exceptions
§ Assertions
§ Defensive programming

www.codemasterinstitute.com
3
Definitions

§ Testing: is an act of examining whether a given

piece of program meets the program
requirements
§ Debugging: is the process of finding and fixing
the program errors
§ Exception Handling: is a mechanism to handle
runtime errors in a program

www.codemasterinstitute.com
4
Defensive Programming

§ Write specifications for functions

§ Modularise programs
§ Check conditions on inputs/outputs

Testing/Validation Debugging
§ Compare input/output § Study events leading to
pairs to specification an error
– "it's not working" – "Why is it not working?"
– "How can I break my – "How can I fix my
program?" program?"

www.codemasterinstitute.com 5
What You Should Do

§ From the start, design your code to ease the

subsequent testing and debugging
§ Break your program up into modules that can be
tested and debugged individually
§ Document the constraints of your modules
– What do you expect the input to be?
– What do you expect the output to be?
§ Document assumptions behind the code design

www.codemasterinstitute.com
6
When Are You Ready to Test?

§ Ensure the code runs

– Remove syntax errors
– Remove static semantic errors
– Python interpreter can usually find these for you
§ Have a set of expected results
– an input set
– for each input, the expected output

www.codemasterinstitute.com
7
Types of Tests

§ Unit testing
– validate each piece of program
– test each function separately
§ Regression testing
– add test for bugs as you find them
– catch reintroduced errors that were previously fixed
§ Integration testing
– does overall program work?
– Tend to rush to do this

www.codemasterinstitute.com
8
Testing Methods

§ Intuition about the natural boundaries to the

problem
def is_bigger(x,y):
""" Assumes x and y are ints
returns True if y is less than x , else False"""

§ If no natural partitions, might do random testing

– probability that code is correct increases with more
tests
– better options below
§ Black box testing
– explore paths through specification
§ Glass box testing
– explore paths through code
www.codemasterinstitute.com
9
Black Box Testing

§ Design the test cases without looking at the code

§ This can be done by someone other than the
implementer to avoid implementer biases
§ The test can be reused if implementation
changes
§ Paths through specification
– builds test cases in different natural space partitions
– Also consider boundary conditions (empty lists,
singleton list, large numbers, small numbers, etc)

www.codemasterinstitute.com
10
Black Box Testing
def sqrt(x, eps):
""" Assumes x, eps floats, x >= 0, eps > 0
Returns res such that x-eps <= res*res <= x+eps """
CASE x eps
boundary 0 0.0001
perfect square 25 0.0001
less than 1 0.05 0.0001
irrational square root 2 0.0001
negative number -4 0.0001
negative eps 35 -0.001
extremes 2 1.0/2.0**64.0
extremes 1.0/2.0**64.0 1.0/2.0**64.0
extremes 2.0**64.0 1.0/2.0**64.0
extremes 1.0/2.0**64.0 2.0**64.0
extremes 2.0**64.0 2.0**64.0
www.codemasterinstitute.com
11
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
§ What are some drawbacks of this type of testing?
– can go through loops arbitrarily many times
– missing paths
§ Guidelines
– branches
Ø exercise all branches 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, cases that catch all ways to exit loop
www.codemasterinstitute.com
12
Glass Box Testing

def abs(x):
""" Assumes x is an int
Returns x if x>=0 and –x otherwise """
if x < -1:
return –x
else:
return x

§ A path-complete test suite could miss a bug

§ Path-complete test suite: 2 and -2
§ But abs(-1) incorrectly returns -1
§ Should still test boundary cases

www.codemasterinstitute.com
13
Debugging

§ Steep learning curve

§ Goal is to have a bug-free program
§ Tools
– Built in to IDLE and Anaconda
(https://www.anaconda.com/products/distribution)
– Python tutor (https://pythontutor.com/)
– print statement
– Use your brain, be systematic in your hunt

www.codemasterinstitute.com
14
Print Statement

§ Good way to test hypothesis

§ When to print
– enter function
– parameters
– Function results
§ Use bisection method
– put print halfway in code
– decide where bug may depending on values

www.codemasterinstitute.com
15
Debugging Steps

§ Study program code

– don’t ask what is wrong
– ask how did I get the unexpected results
§ Scientific method
– study available data
– form hypothesis
– repeatable experiments
– pick simplest input to test with

www.codemasterinstitute.com
16
Error Message - Easy

§ Trying to access beyond the limit of a list

test = [1,2,3] then test[4] -> IndexError

§ Trying to convert an inappropriate type

int(test) -> TypeError

§ Referencing a non-existent variable

a -> NameError

§ Mixing data types without appropriate coercion

'3'/4 -> TypeError

§ Forgetting to close parenthesis, quotation, etc

a = len([1,2,3)
print(a) -> SyntaxError
www.codemasterinstitute.com
17
Logic Errors - Hard

§ Think before writing new code

§ Draw pictures, take a break
§ Explain the code to
– Someone else
– A rubber ducky (explain you code to a toy duck)

www.codemasterinstitute.com
18
Logic Errors - Hard

DON’T DO
• Write entire program • Write a function
• Test entire program • Test the function, debug the function
• Debug entire program • Write a function
• Test the function, debug the function
• *** Do integration testing ***

• Change code • Backup code

• Remember where bug was • Change code
• Test code • Write down potential bug in a
comment
• Forget where bug was or what change • Test code
you made • Compare new version with old
• Panic version

19
Exceptions

§ What happens when procedure execution hits an

unexpected condition?
§ Python interpreter throws you an exception (to
what was expected)
– trying to access beyond list limits
test = [1,7,4]
x = test[4] -> IndexError
– trying to convert an inappropriate type
x = int(test) -> TypeError

– trying to open a non-existent file

file = open("foo") -> FileNotFoundError

– trying to open a read-only file for writing

file = open("test.txt", "w") -> PermissionError
www.codemasterinstitute.com
20
More Examples of Exceptions

§ Some of the common exceptions:

– SyntaxError: Python can't parse the program
– NameError: local or global name not found
– TypeError: operand doesn't have correct type
– ValueError: operand type ok, but value is illegal (eg,
int("hello"))
– IOError: IO system reports malfunction (eg, file not
found)

www.codemasterinstitute.com
21
Why Exception Handling?

§ When something that is not what you usually

expected occurs, there are two ways to handle it.
§ Take the example of reading student records
from a file and print out the names of those who
are enrolled in MIT course, the main thrust of the
logic is
1. students = open( the file )
2. for st in students:
3. if st is an MIT student:
4. print the name of the student
5. close the file
6. print "bye-bye"

§ The above program logic is simple, clear and

easy to follow. www.codemasterinstitute.com 22
Why Exception Handling?

§ What would happen if the file doesn't exist, or

there is no permission to read the file?
– to deal with these types of "abnormal" conditions, we
need to add more steps
1. students = open( the file )
2. if the file doesn’t exits:
3. print the file doesn’t exist
4. exit
5. elif no permission to read the file:
6. print cannot read the file
7. exit
8. for st in students:
9. if st is an MIT student:
10. print the name of the student
11. close the file
12. print "bye-bye"
www.codemasterinstitute.com
23
Why Exception Handling?

§ The new version is obviously more correct than

the first version, but it also
– obscure the primary task of the program – to read a
student file and print out the names of MIT students!
– distract our attention to the main task of the program
Ø your attention is equally shared between dealing an
abnormal condition and getting the names of MIT students.
§ This is the first approach.

www.codemasterinstitute.com
24
Why Exception Handling?

§ The second approach is treating the no file or no

read permission as exceptional conditions, and
they are handled elsewhere, not allowing the
handling of these abnormal conditions to distract
you from the main task of your program!
§ Most modern programming languages support
this approach with the try–except statement
(Python syntax):
try:
the main task
except abnormal condition 1:
handling abnormal condition 1
except abnormal condition 2:
handle abnormal condition 2
except:
handle all other abnormal conditions
www.codemasterinstitute.com
25
Why Exception Handling?

§ When something abnormal occurs, an Exception

object is thrown (or raised). This object contains
the details of the abnormal condition.
§ The program may choose to catch this exception
object, or ignore it.
– However, if you ignore it, your program would crash!
§ For example, when you call function open to
open a file, and the system find the file doesn’t
exist, the open function would raise an
FileNotFoundError exception.
– You may catch this exception and handle it in a separate
place (an except clause)
– or you may ignore it – your program would crash!
www.codemasterinstitute.com
26
Why Exception Handling?

§ Let's re-write the pseudo-code with the try-

except statement:
1. try:
2. students = open( the file )
3. for st in students:
4. if st is an MIT student:
5. print the name of the student
6. close the file
7. print "bye-bye"
8. except (FileNotFoundError, PermissionError):
9. print the error message
10. except:
11. print error opening file

§ The main task and the abnormal conditions are

processed in different places, allowing you to
focus on main issue of the program!
www.codemasterinstitute.com
27
Multiple except Clauses

§ The try-except statement may have multiple

except clause, each handling one type of error.
try:
a = int(input("Tell me one number: "))
b = int(input("Tell me another number: "))
print("a/b = ", a/b)
print("a+b = ", a+b)
except ValueError:
print("Could not convert to a number.")
except ZeroDivisionError:
print("Can't divide by zero!")
except:
print("Something went wrong!")

Note: the code in an except clause is executed only if an exception is raised in the
try block. If an exception is raised but it is not ValueError or
ZeroDivisionError, the code in the last except clause is executed.
www.codemasterinstitute.com
28
The else and finally Clause

§ The try-except statement may have an optional

else clause and optional finally clause:

try:
statements
except:
statements
else:
statements (executed only if there is no exception)
finally:
statements (always executed, used to clean-up
code that should be run no matter what else
happened, eg, close a file)

www.codemasterinstitute.com
29
What to Do with an Error?

§ What to do when encounter an error?

§ Fail silently:
– Substitute default values or just continue
– Bad idea! User gets no warning
§ Return an "error" value
– What value to choose?
– Complicates code having to check for a special value
§ Stop execution, signal an error condition
– raise an exception
raise Exception("a descriptive message")

www.codemasterinstitute.com
30
Raise an Exception

§ When unable to produce a result consistent with

the function's specification, raise an exception:
raise <exception>(<argument>)
ise ou
d

m a s ut
sa ng
or

ra r y

b
yw

es tri
ge
th lly al,
to ro
ke

nt f er

wi pica ion
ty opt
wa e o
m

a
na

§ Example:
raise ValueError("something is wrong")

www.codemasterinstitute.com
31
Example: Raise an Exception
def get_ratios(L1, L2):
""" Assumes: L1 and L2 are lists of equal length of numbers
Returns: a list containing L1[i]/L2[i] """
ratios = []
for i in range(len(L1)):
try:
ratios.append(L1[i]/L2[i])
except ZeroDivisionError:
ratios.append(float('nan')) # nan = not a number
except:
raise ValueError("get_ratios called with a bad arg")
return ratios

n1 = [3.9, 10.5, "pi", 23.1]

n2 = [4.5, 0.0, 7.9, 91.1]
try:
n1_over_n2 = get_ratios(n1, n2)
except ValueError:
print("There are bad numbers in the lists")

www.codemasterinstitute.com
32
Assertions

§ Want to be sure that assumptions on state of

computation are as expected?
§ Use an assert statement to raise an
AssertionError exception if assumptions are not
met:
– This is an example of good defensive programming
def avg(marks):
assert len(marks) != 0, 'no marks data'
return sum(marks) / len(marks)
§ Raise an AssertionError if it is given an empty
list for marks.
§ Otherwise runs ok
www.codemasterinstitute.com
33
Assertions As Defensive
Programming
§ Assertions don’t allow a programmer to control
response to unexpected conditions.
§ Ensure that execution halts whenever an
expected condition is not met.
§ Typically used to check inputs to functions, but
can be used anywhere.
§ Can be used to check outputs of a function to
avoid propagating bad values.
§ Can make it easier to locate a source of a bug!

www.codemasterinstitute.com
34
Where to Use Assertions

§ Goal is to spot bugs as soon as introduced and

make clear where they happened.
§ Use as a supplement to testing.
§ Raise exceptions if users supplied bad data input.
§ Use assertions to
– Check types of arguments or values
– Check that invariants on data structures are met (eg,
in a sorted list of numbers, an earlier number should
not be larger than a later number)
– Check constraints on return values
– Check for violations of constraints on procedure (eg,
no duplicates in a list)
www.codemasterinstitute.com
35
Summary

§ Testing
§ Debugging
§ Catch exceptions
§ Raise exceptions
§ Assertions
§ Defensive programming

www.codemasterinstitute.com
36
Acknowledgement

§ geekforgeek
§ Python Tutor
§ MIT OCW

www.codemasterinstitute.com
37