Testing and Debugging

Writing reliable code is hard. This is why we need to design & run tests to check that the code does what it is meant to do and then use debugging techniques to find and fix any problems.

There are four types of error we should identify:

Syntax Errors - code that is nonsensical to the interpreter or compiler. E.g., mistyped keywords, missing quotes on a string, invalid variable names, wrong indentation (in Python), unmatched brackets, etc...
Compile-time errors - these are things that would prevent a compiler from compiling your code, e.g., incompatible data types, using an undefined/undeclared variable or function, etc...
Run-time errors - Things that go wrong during the running of the program that usually make it crash, e.g., Division by Zero, Integer Overflow (maybe caused by and infinite loop), Unusable user input, etc...
Logic errors - the code runs without crashing but does not produce the correct result. These happen due to mistakes in understanding/designing a solution to the problem and are often the hardest errors to find and correct.

In interpreted languages (like Python) there are no compile-time errors, so both compile-time-like and run-time errors will crash the program due to unhandled exceptions.

Although there are static analysis tools that will act like a compiler and help you find errors before you run your code.

Back to Unit 4 Programming

See 9.2-9.3 in the textbook

TODO
Add more examples and exercises

Testing Code

Code should be tested regularly as it's being written - testing different modules as they are written and assembled. A wide range of values and situations should be tested, ensuring that you cover at least the following three categories:

Normal values
- Values of the correct type and in expected range
Extreme (Boundary) values
- Values of the correct type and on the limits/extremes of the expected range or at boundary points of the algorithm
Abnormal values
- Values out of expected range (e.g., negative or >100 for percentages) or of the wrong type.

For each test you should know what the expected outcome is BEFORE you run the test. This way you can ensure your program is working as expected. You can document your tests in a test table with the columns

test type | input data | expected output | actual output | pass/fail | action taken

The three central bold columns are required - the other columns are strongly recommended.

If a test fails then the program needs to be fixed to make the test pass. This might require the use of debugging techniques (see below) to identify what/where the error is.

If all tests pass then your code might be correct! Write some more tests to be more sure :)

Debugging Code

Print statements - quick debugging, just print out the values of variables inside your code to check if they are doing what you thought they should.
Debugger & Line-stepping - built into IDEs or as terminal programs, help you step through and investigate your code as its running. See below for using the debugger in Mu Editor.
Trace tables - for logic errors that are hard to identify, run your pseudocode by hand to check your understanding.

Using a debugger

To use the debugger you need to create one or more break points in your code. When you run your code using the Debug button it will stop at these break points and wait for you to look at the current state of the program and chose what to do next.

Once your code has stopped at a break point you can view all of the variables in your code (some debuggers also let you modify their values and run code in the console). You can then Step Over to run each line of the code line-by-line or Continue to the next break point.

Step-In and Step-Out are used to enter and exit function or method calls.

Once you've identified where the code was broken / had the unwanted behaviour, then you can fix it and run your tests again!

Exercises

The get_grade function is meant to calculate a letter grade given mark and a list of cut-offs. It has problems... fix them!

def get_grade(mark, ABCD_cutoffs):

  """Returns the letter grade for a mark \

  given the cutoffs for A, B, C and D.

  A mark below the D boundary receives an F.

"""

  GRADES = ['A', 'B', 'C', 'D]

  grade == 'F'

  for idx in range(4)

    if mark >= ABCD_cutoffs[idx]:

      grade = GRADES[idx]

  return grade

# test grades A   B   C   D

boundaries = [80, 70, 60, 50]

# write your test data

Create a set of appropriate test data and document it in a test table
Convert the Python function to a flowchart or pseudocode submodule:

START get_grade(mark, cutoffs) DECLARE GRADES ← ['A', 'B', 'C', 'D'] .... RETURN gradeEND get_grade

Given the boundaries [80, 70, 60, 50] create a trace table for the mark 75
Compare the trace table to a debug session
Identify the problem and fix the code
- test your fix using your test data
How could we validate the inputs?
Create a test table for your corrected/extended Python program

Example Solution

Report abuse