MYP Design Debugging and Testing Code Notes

Three Kinds of Error, Three Kinds of Hunt

1. A syntax error breaks the rules of the language, such as a missing colon or an unclosed bracket, and the program refuses to start at all.
2. A runtime error lets the program start and then stops it partway, like dividing by zero or casting int("twelve").
3. A logic error runs perfectly and gives the wrong answer, which makes it the one that costs you a week.
4. Syntax errors take seconds to fix because the editor underlines the line for you.
5. Logic errors only turn up when you test, since nothing inside the machine knows what you meant it to do.

An Error Message Tells You Where and What

1. Read a Python error from the bottom upwards, because the last line names the error type and the line above gives you the line number.
2. "SyntaxError: invalid syntax" often points at the line after the real mistake, since that is where the computer first noticed something was wrong.
3. "NameError: name 'tempreature' is not defined" is a spelling mistake nearly every single time.
4. "IndexError: list index out of range" means you asked for item 5 of a list that only holds four things.
5. Searching the exact error text online is fair research, as long as you record in your folder what you changed and why.

Print Statements Show You What the Program Believes

1. Print statement tracing means dropping a print into the middle of your code to see what a value really is at that moment.
2. Always print a label alongside the value, so print("moisture =", moisture) tells you which print you are reading.
3. Put one print before and one after a suspect line to see whether that line changed anything at all.
4. A print inside a loop tells you whether the loop ran once, ten times, or is still going.
5. Take them out or comment them before you submit, because a screen of debugging output reads as unfinished work.

Trace Tables Follow the Values by Hand

1. A trace table has one column per variable and one row per step, filled in as you pretend to be the computer.
2. Add a column for the condition of every loop and if, and write True or False in it each time round.
3. Doing this on paper catches logic errors that a computer will happily run without a word of complaint.
4. The first row where your table disagrees with what you expected is the line the bug is hiding on.
5. Only trace the section you suspect, because tracing 200 lines by hand costs an evening and teaches you nothing.

Breakpoints Stop the Program Where You Want

1. A breakpoint tells the editor to pause the program on a line you choose so you can inspect every variable at once.
2. In Thonny or VS Code you set one by clicking in the margin next to the line number.
3. Once it is paused, "step over" runs the next line and "step into" takes you inside a function call.
4. Breakpoints beat prints when there are many variables, because you see all of them without typing a thing.
5. Prints beat breakpoints on a micro:bit, where the code is running on the board instead of inside the editor.

A Test Plan Turns Guessing Into Evidence

1. A test plan is a table you write before testing, listing what you will put in and what should come out.
2. Normal data is an everyday value the program should handle, such as 21 degrees for a room thermostat.
3. Boundary data sits exactly on the edge of a rule, so for "alert above 30" you test 29, 30 and 31.
4. Erroneous data is something the program should refuse, like the word "hot" or a reading of minus 300 degrees.
5. Write the expected result before you run the test, since deciding afterwards means agreeing with whatever the program did.
6. Record the actual result and any change you made, because that record is your evidence for Evaluating.