Then the coursework tests run, and the screen fills with red.
I’ve sat next to students at that exact moment for ten years, and the look never changes. Disbelief first, then a small wave of panic. “But it worked a minute ago.”
It did work. It worked for the inputs you tried. The test just asked a question you hadn’t thought to ask.
So let’s learn to find that question quickly, without rewriting half your code at 1am.
Your Code Isn’t Broken, Your Assumptions Are
Picture a function that averages a list of numbers. Give it 10, 20, 30 and it returns 20. Lovely.
Now try one number. Then negative ones. Then an empty list, and it crashes, because you can’t divide by zero items.
The maths was never wrong. Your code simply assumed the list would always have something in it, and nobody told it otherwise.
That’s what a bug usually is. Not a typo, but a belief your code holds that isn’t always true. Once you see it that way, a failed test stops feeling personal and starts feeling like a clue.
The Night One Empty List Nearly Cost a Grade
A few years ago, a student I’ll call Priya came to me the night before a submission. Her program passed everything she threw at it. The hidden tests failed four out of ten.
She had already rewritten her sorting function twice. Both versions failed in exactly the same places, which told me sorting wasn’t the problem.
So we didn’t touch the code. We read the failed test names aloud instead. Three of the four had “empty” or “single” in them, and her program had never once met a list with fewer than two items.
One line fixed it. Two hours of rewriting had been aimed at the wrong target.
Three Kinds of Failure, Three Different Hunts
Before you change anything, work out what sort of failure you’re facing, because each is hunted differently.
A syntax error breaks the rules of the language, like a missing bracket or a bad indent. Your editor usually points straight at it. A runtime error happens while the program runs, such as dividing by zero or reaching for a list position that doesn’t exist. The message names the line, which is a decent start.
Logic errors are the sneaky ones. Nothing crashes, but the answer is wrong. If your code takes 10% off a price by subtracting 10, a £50 item becomes £40 instead of £45. No warning, no red text, just a quietly wrong number.
Most coursework marks are lost to logic errors, because a program that runs feels like a program that works.
The Habit Nobody Teaches: Predict Before You Run
Students often go searching for the best computer science coursework help, hoping for a clever trick. The nearest thing I know is a habit so simple it gets overlooked.
Before you run the code, write down what you expect it to produce. One line on paper or in a comment is plenty.
Then run it. If the output differs, you’ve found the exact moment your mental picture and the program disagree. That gap is your bug, and it’s far easier to spot once you’ve committed to a prediction.
I’d add a bug ledger too: a notebook or text file noting what you suspected, what you changed and what happened. It sounds fussy, but after two hours at the same screen it stops you trying the same failed fix a third time. It also gives a tutor something real to look at if you need to ask for help.
Read the Tests Like a Marker
Tests aren’t random. They usually mirror the marking criteria, so every failing test points at something your marker cares about.
Most of them poke the same handful of edges: zero, an empty input, exactly one item, the first and last position in a list, values just above or below a limit, and the wrong type, like text where a number belongs. Check those before anything exotic.
The classic edge failure is the off-by-one error. A loop meant to handle every item stops one short, because the programmer mixed up how many items there are with the index of the last one.
It survives so long because the output looks nearly right. Trace the loop by hand with a three-item list and you’ll often spot it within a minute.
What I Do When a Test Fails
This is the order I actually work in, whatever the language.
First I reproduce it, using the exact input that failed, and write the expected and actual outputs side by side. Then I shrink it. If it fails with 100 values, I hunt for the smallest list that still fails, because two or three items leave far fewer suspects.
Next I look inside by printing the in-between values. Back to our average:
def calculate_average(numbers):
return sum(numbers) / len(numbers)Checking sum(numbers) and len(numbers) separately shows the second is 0 on an empty list, and the culprit is obvious.
Then I fix the assumption, not the symptom. Decide what the function should do with nothing in it, and say so clearly:
def calculate_average(numbers):
if not numbers:
raise ValueError("Cannot average an empty list")
return sum(numbers) / len(numbers)If your brief says to return None instead, follow the brief. The specification always wins.
Last, I retest widely: the failing input, then [10, 20, 30], [7], [-4, 2] and []. Every test should challenge an assumption, not just pad the count.
Mistakes I’ve Made Myself
I’ve made most of these, so there’s no judgement here.
Changing five things at once is the big one. If it suddenly works, you won’t know why, and one change may be hiding a different bug that turns up later.
Trusting the error message completely is another. It tells you where the problem showed up, not always where it started. If a variable is wrong by the time it reaches a calculation, trace backwards to where it first went wrong.
Deleting a failing test is tempting, but ask whether it matches the assignment first. Usually it does, and it’s right. The same goes for wrapping everything in a catch-all that returns a convenient value. The crash stops, but the faulty logic is still there, now hidden.
And testing only the example in the brief tells you about one behaviour and nothing about empty inputs or bad data.
What I’d Want You to Take Away
A failed test isn’t a verdict on you as a programmer. It’s information, and a generous kind, because it shows you exactly where your understanding has a gap.
So predict, reproduce, shrink, look inside, and make one change you can explain. Then test it properly.
The student who can say why a fix works will always beat the one whose code merely happens to pass. Next time the screen turns red, take a breath and open your ledger. You’re closer than you think.
