“I just can’t figure out why my program doesn’t work. Can someone help me?”
“I’ve been working on this for hours and I’m still stuck.”
“I had it working a few minutes ago, but I did something and now nothing works!”
Making Your Own Private Hell
You probably mastered a few basics, like writing a simple Python program. You’ve gained confidence that you can write a loop or a function. You can see how a basic Python program works. You are hungry for more.
Maybe you are plowing through a book or a course on Python. Maybe it’s a class you’re taking. Or maybe you are getting ambitious and you decide to create something new, like a Reddit bot.
You are busy adding working code. You test every now and then by running the program. If there’s a problem, you edit the file and run the program again. Everything seems so easy.
Then you realize something is wrong. That part you tested 10 minutes ago, by hand, but didn’t test until just now… it’s not working. Are you just imagining this? No, you try it again. It’s still wrong. It’s still broken. If you run the program 10 more times, magic will happen and it will work. Right?
Again and again you try to fix the problem, but it only ends up somehow worse than before. Minutes turn into hours. Time is slipping by. You are so frustrated you are ready to hurl your computer out the nearest window. Why did you think you could do this programming thing anyway? It’s impossible! Only computer geniuses could keep all this straight. And this is just a basic program!
“Is it too late to get my money back?”, you think.
The Way Out
What if you could avoid all of this misery? Imagine if you could use Python itself to check if your new program was correct every time you made a change? As soon as you made any change, you could check to see if you made a mistake. You could find out right away if the change you just made made things better or worse?
Think about this: if you can check your program after every change, and you keep the changes small, then you only have to undo a small change to get back on track. This would keep you from wasting your time with big changes that will derail you for hours or days.
You should write automated software tests. When I say “automated” I mean tests you don’t have to keep in your meat brain. You just have to remember to run a single command to run every test instead of remembering to run a program multiple times to check every situation.
There’s another important benefit to these tests – it’s a professional habit. Writing tests differentiates the pros from the slobs. Writing tests for your program is like basic sanitation for doctors. Would you trust a doctor to perform surgery without washing their hands first?
Writing Tests – A Detailed Example
In this example, we already have a Python source file called rational.py.
For now, I just want you to get comfortable with the tools of creating and then running your first real tests. That’s what you’ll learn today.
You’ll get the most out of this example by following along and running the examples. The original program is located here. If you are familiar with git, you can clone the repository. Otherwise you can just copy the source code locally.
First let’s look at files in the original project.
The rational.py is the implementation and rationaltest.py is a test driver.
The test driver in this project is a “poor man’s” test framework. It’s functional, sure. If you run the file you’ll get a result like this:
We’re going to use the rationaltest.py to make our first tests easy to write. You only have to concern yourself with how to construct the tests using a testing framework. We’ll use pytest for this example.
Let’s run pytest and see what happens:
Just as we expected, no test were run. Let’s add the file that will hold the tests. Let’s call the test file test_rational.py. The name is important.
As mentioned in the pytest documentation, the framework uses standard test discovery to find and run tests.
We’re concerned with 2 basic rules in this example:
- files named test_*.py in the directory
- files named *_test.py in the directory
Let’s run the pytest command again with our new (empty) test file, test_rational.py.
Again, no tests were detected, so no tests ran. Let’s add a test.
If we use the existing smoke test file as a guide, you’ll see a series of tests lists. As a general rule, it’s easier to test the behavior of code that has the fewest dependencies. What do I mean by this?
Looking at the Rational class, you might be tempted to start testing there. However, you’ll see that the implementation of that class depends on another function, gcd.
If a test of the Rational class fails we can’t be sure that the class is responsible for the error. At least not yet. We should drill further into the dependency of the class and start with the “bricks” the foundation of the Rational class is built upon.
This is why gcd is a good candidate. The comments in the function tell us that it’s based on Euclid’s algorithm for finding the greatest common denominator (gcd) of 2 integers.
Since we know the general expectations of how gcd works, we can start with a simple test case. On paper, Euclid’s algorithm predicts the gcd(3,0) will be 3.
Our test file now looks like this:
def test_gcd_a_0_is_0():
assert True
If we run pytest again:
So far, so good. Let’s replace the assertion with a real test, but with a clearly wrong answer.
def test_gcd_a_0_is_0():
assert rational.gcd(3,0) == 100000
You might wonder why would add a test that is going to fail. We want to verify that the test we are creating is going to run and that if there is an error in the test we’ll catch it.
Consider how blind we would be if we created a faulty test and the test framework ignored the failing test. How much time would we waste building on this false assumption? It’s better to check now, at the start, and catch stupid mistakes before they cost us an arm and a leg.
Isn’t that great? pytest tells you exactly where it fails and why. Let’s repair the test with the correct expected value.
def test_gcd_a_0_is_0():
assert rational.gcd(3,0) == 3
Then verify that with pytest:
That’s it, you did it! You created a test and know you know how to build more. Instead of trying to remember each test case and run them manually, you only have to run one command to run all the tests.
That feeling you have right now? That’s the feeling of victory over chaos.