Learn Python in 30 Days — Day 26: Testing & Debugging

Day 26: Testing & Debugging

Welcome to Day 26 of the Learn Python in 30 Days series!

By this point in the series, you’ve written loops, functions, files, classes, and even started structuring real programs.
Today is about something every programmer does, debugging.

Debugging isn’t a punishment or a sign you “broke it.”
It’s simply the process of understanding your code’s behaviour.

In fact, if you work on real projects, debugging becomes one of your greatest skills. Hopefully I can show you some basic methods of debugging to get you started.

All example files for this series are available on my GitHub: Learn-Python-in-30-Days

Print Debugging

The simplest, fastest, most reliable debugging tool is print()

Print debugging is just checking what your variables contain at different points.

Example: Something isn’t adding up

def total_price(prices):
    total = 0
    for p in prices:
        total += p
    return total

items = ["4.99", "2.50", "10.00"]
print(total_price(items))

Why does this crash? Add debug prints to help find out: -

def total_price(prices):
    total = 0
    for p in prices:
        print("DEBUG: p =", p, "| type:", type(p))
        total += float(p)
    return total

Now you see the problem: the prices are strings.
Print debugging isn’t fancy, but it’s effective.

Try it yourself, hopefully you'll see something like that shown below: -

You can also download this example from my GitHub here and run it yourself.

When to use print debugging

• When your program crashes unexpectedly

• When a variable isn’t what you expect

• When a function “does nothing”

• When logic depends on multiple steps, especially loops

Add and remove prints freely during development — they’re temporary tools, not permanent code.

Tracing Logic: Follow the Flow Step-by-Step

A huge portion of debugging is simply checking, what happened first? Then what? And what next?

Python executes line by line, so if you don’t understand the flow, things feel chaotic.

Let’s trace a function that behaves oddly:

def validate_age(age):
    if age > 18:
        return "Adult"
    elif age > 12:
        return "Teen"
    else:
        return "Child"

print(validate_age("20"))

Again why does this crash? Let’s trace it using the simple print() method:

def validate_age(age):
    print("Incoming age:", age, type(age))
    if age > 18:
        print("Compared age > 18")
        return "Adult"
    elif age > 12:
        print("Compared age > 12")
        return "Teen"
    else:
        print("Fallback: Child")
        return "Child"

You’ll instantly see the issue:
Python can’t compare a string and a number.

Try it yourself, hopefully you'll see something like that shown below: -

You can also download this example from my GitHub here and run it yourself.

Catching Errors Cleanly (try/except)

You’ve seen this back on Day 17 – Error Handling.
Today we expand it and show how debugging and testing use it together.

Example: Safe user input

def get_number():
    try:
        value = int(input("Enter a number: "))
        return value
    except ValueError:
        print("That wasn’t a number — try again.")
        return get_number()

num = get_number()
print("You entered:", num)

Why this works well:

• Your code fails gracefully

• Users don’t see scary error messages

• The error becomes part of your logic (retrying)

Example: Debugging inside try/except

try:
    result = 10 / x
except Exception as e:
    print("DEBUG:", e.__class__.__name__, "-", e)

This prints:

DEBUG: NameError - name 'x' is not defined

You get both the type and the message, which makes debugging 10× faster.

Try it yourself, hopefully you'll see something like that shown below: -

You can also download this example from my GitHub here and run it yourself.

Micro-Testing

Before you learn full testing frameworks, there’s something even more useful, using test tiny bits of code immediately after you write them.

Example: You write a function:

def square(n):
    return n * n

Test instantly:

print(square(2))   # Expect 4
print(square(-3))  # Expect 9
print(square(0))   # Expect 0

If these work, the function is reliable.
Later, if a bug appears, you know the issue isn’t inside this function  it’s elsewhere.

What should you test?

• Functions with math

• Anything involving strings

• Anything involving input

• Anything involving files

• Every function used in your final project

Testing = confidence.
Debugging = understanding.
Together, they make you a real developer.

Try it yourself, hopefully you'll see something like that shown below: -

You can also download this example from my GitHub here and run it yourself.

A Debugging Method You Can Use Every Day

Here’s a simple 5-step strategy you can follow for the rest of your Python journey:

1. Recreate the bug, if you can’t repeat it, you can’t fix it.

2. Add print()s to inspect variables, check types, values, paths, and flow.

3. Trace the logic, which line runs first? Which conditions fire?

4. Catch errors cleanly, turn crashes into clues.

5. Test small pieces separately, don’t test a whole program at once.

Next Up — Day 27 – Mini Project: Rock Paper Scissors

Tomorrow, we'll pull together things we've learnt over the past 26 days into a mini-project.

All example files for this series are available on my GitHub: Learn-Python-in-30-Days
You can see the full series here Learn Python in 30 Days series!

Hope you have enjoyed this post, thanks Matty