In the last post, we ran into a problem with the file dependency. A little foresight also indicated that this will become a bigger problem as we go.
What we really need is a way to fake the file. Right now the details of this implementation are internal to the Task
class. So, in order to test this effectively, we are going to have to change some things. Let's get started!
todo/task.py
class Task:
def add(s):
f = open('todo.txt', 'a')
f.write(s)
f.write("\n")
f.close()
s = '"'+s+'"'
print(f"Added todo: {s}")
This portion of the Task
is the add
method that we are interested in testing. Notice on the first line in the method, we are direction opening the file. This file, it follows, is a dependency of this method. That is, add
depends on the todo.txt
file. The problem is that we do not have an enabling point to use to inject custom behavior (which is what we want for the test).
Pulling Behavior Up
Now, we could pass in the filename to the add
method. That would give us an enabling point, but it still suffers from the problem that it's looking at a file on disk. It also affects our API in a suboptimal way.
In this context, by API I mean the application programming interface. Namely, the way the method is called. Adding the filename would change our API from:
Task.add('Buy Milk')
to:Task.add('Buy Milk', 'todo.txt')
.
As a matter of design, it also associates a unexpected parameter with a basic function of a task. How can we accomplish this in a better way? We could use the constructor:
class Task:
def __init__(self, filename: str):
self.f = open(filename, 'a')
def add(self, s):
self.f.write(s)
self.f.write("\n")
self.f.close()
s = '"'+s+'"'
print(f"Added todo: {s}")
In this method, we pass the filename into the constructor. This gives us our enabling point: I can construct a Task
with a different filename. This still isn't ideal, but that's the process that we are working through right now. We are pulling behavior up step-by-step.
Breaking the Dependency
When I refer to pulling behavior up, I mean up in the call stack. To be concrete, the file behavior now happens before we call add, when we construct the Task
. Unfortunately, we are still tied to the filesystem. How do we fix this? By changing our input:
todo/task.py
class Task:
def __init__(self, file):
self.file = file
def add(self, s):
self.file.write(s)
self.file.write("\n")
s = '"'+s+'"'
print(f"Added todo: {s}")
Here is how our client code would be affected:
todo.py
with open('todo.txt', 'a') as f:
task = Task(f)
task.add(''.join(args[2:]))
More progress! We have pulled the dependency out of the Task
class (in this scenario). What is the advantage? Well, now we can inject our own file when testing. We could use a test file. But, that file dependency re-introduces the problem -- that tests could affect each other by changing the file on disk. So what's the solution? Fake the file using a Python object.
Stubbing Out a Fake File
For testing purposes, we'll need a fake file. To do that, we will have to create our own class that responds to the same interface as the file. Actually, right now we only care about writing, because that is the only method being invoked on the file in the method.
class FakeFile:
pass
Starting from a blank implementation, as we have before. Now, let's fake the write
interface.
class FakeFile:
def write(self, message: str):
pass
Now we can use this stub in our tests! Let's add our test for Task.add
:
tests/test_task.py
def test_adding_task(capsys):
fake_file = FakeFile()
task = Task(fake_file)
task.add("Buy Bread")
captured = capsys.readouterr()
assert "Buy Bread" in captured.out
poetry run pytest
# tests/test_task.py ..
# 2 passed in 0.01s
And it passes! So we have:
- Broken the file dependency
- Faked the file to test our
add
method - Passed in the file into the constructor in the client code
This may seem a little suspect. So, if you're like me, you'll want to see this fail too. Let's make that happen. Let's break it in the simplest possible way. We'll just update the expectation.
def test_adding_task(capsys):
fake_file = FakeFile()
task = Task(fake_file)
task.add("Buy Bread")
captured = capsys.readouterr()
assert "Sell Bread" in captured.out
poetry run pytest
# FAILED tests/test_task.py::test_adding_task - assert 'Sell Bread' in 'Added todo: "Buy Bread"\n'
And we get a failure. Now we can feel more confident that this test gives us meaningful feedback. Swap the expectation back and run tests again to verify we are back to Green.
def test_adding_task(capsys):
fake_file = FakeFile()
task = Task(fake_file)
task.add("Buy Bread")
captured = capsys.readouterr()
assert "Buy Bread" in captured.out
poetry run pytest
# tests/test_task.py ..
# 2 passed in 0.01s
Okay, here's the best part: running this test does not change the file on disk, because it's just using the fake object. This makes our tests:
- Focused on our domain
- Less brittle
- Independent of the file system
Next time, we will update the Task.ls
test to use the fake file and then write the remainder of the tests needed for Task
. You may have noticed a lot of this functionality doesn't really belong in Task
-- you're right, it should be in TaskList
. We'll create those objects and tests iteratively as we continue.
Key Takeaways
- Break dependencies by pulling them up into the constructor
- Pass in those dependencies in client code
- Create fake dependencies for your tests
Top comments (0)