Pattern #1 — Test The Real API
The most simple way to test this is to use the real API.
"""Pattern 1 - Full Integration Test"""
from src.file_uploader import upload_file
def test_upload_file():
file_name = "sample.txt"
response = upload_file(file_name)
assert response["success"] is True
assert response["name"] == file_name
assert response["key"] is not NoneFirst, create a simple TXT file in the same folder and call it sample.txt .
Let’s move on to Mocking, which in my opinion is an Anti-Pattern for testing 3rd party API integrations.
Let’s learn what NOT to do.
Pattern 2- Mocking/Patching The Requests Library
The most straightforward way is to Mock the requests library.
"""Pattern 2 - Mock the Request Library"""
from unittest.mock import patch, Mock, ANY
from src.file_uploader import upload_file
def test_upload_file():
file_name = "sample.txt"
stub_upload_response = {
"success": True,
"link": "https://file.io/TEST",
"key": "TEST",
"name": file_name,
}
with patch("src.file_uploader.requests.post") as mock_post:
mock_post_response = Mock()
mock_post_response.status_code = 200
mock_post_response.json.return_value = stub_upload_response
mock_post.return_value = mock_post_response
response = upload_file(file_name)
assert response["success"] is True
assert response["link"] == "https://file.io/TEST"
assert response["name"] == file_name
mock_post.assert_called_once_with("https://file.io", files={"file": ANY})If I may ask you, what’s wrong with this or why is this undesirable?
Let’s say your boss tells you to add more functionality. Perhaps the download_file , update_fileor delete_file functionality.
Cons
-
Tightly Coupled to Implementation
-
Brittle and Hard to Maintain
-
Extra Effort to Patch Every Test: You need to remember to apply
@patchor use a context manager in every test that may trigger API calls, increasing test setup requirements. -
Potential for Mixing Business Logic and I/O Concerns
-
Likely Need for Integration and E2E Tests: Since mocks don’t guarantee that the code will work with the actual API, you often need separate integration and end-to-end tests to validate real API behavior.
As you can see I’m not a big fan of this approach for anything other than very simple code.
So what’s the solution?
Pattern #3 — Build an Adaptor/Wrapper Around The 3rd Party API
An interesting idea I got from Harry Percival’s YouTube video — Stop Using Mocks (for a while) — was the concept of an adaptor.
Harry describes it as a wrapper around the 3rd party API or around the I/O.
The wrapper is built to support your interactions with the 3rd party API and is written in your own words (not based directly on the 3rd party Swagger).
src/file_uploader_adaptor.py
import requests
class FileIOAdapter:
API_URL = "https://file.io"
def upload_file(self, file_path):
with open(file_path, "rb") as file:
response = requests.post(self.API_URL, files={"file": file})
return response.json()How could we test it?
We’ll use mock/patch here as well but instead of mocking the requests.post library we’ll patch the upload_file method of the FileIOAdaptor class.
tests/unit/test_pattern3.py
"""Pattern 3 - Create an Adaptor Class and Mock It"""
from unittest import mock
from src.file_uploader_adaptor import FileIOAdapter
def test_upload_file():
with mock.patch(
"src.file_uploader_adaptor.FileIOAdapter.upload_file"
) as mock_upload_file:
mock_upload_file.return_value = {"success": True}
adapter = FileIOAdapter()
response = adapter.upload_file("sample.txt")
assert response == {"success": True}
mock_upload_file.assert_called_once_with("sample.txt")Pattern #4 —Dependency Injection
Next, let’s look at another design pattern — dependency injection.
Instead of having our business logic (upload functionality) baked into the FIleUploader class, how about we pass it as a dependency.
from abc import ABC, abstractmethod
import requests
class FileUploader(ABC):
@abstractmethod
def upload_file(self, file_path: str) -> dict:
raise NotImplementedError("Method not implemented")
class FileIOUploader(FileUploader):
API_URL = "https://file.io"
def upload_file(self, file_path: str) -> dict:
with open(file_path, "rb") as file:
response = requests.post(self.API_URL, files={"file": file})
return response.json()
def process_file_upload(file_path: str, uploader: FileUploader):
response = uploader.upload_file(file_path)
return response
Pattern #5 — Use a Fake with Dependency Injection
The last pattern (Dependency Injection) is really good but still uses mocks.
What if you wanted to avoid mocks completely?
You can use a Fake instead.
Fake is a different kind of test double to mocks and patches — which is an in-memory representation of the object you’re trying to replace. That’s my informal definition.
tests/unit/test_pattern5.py
"""Pattern 5: Dependency Injection + Fake - Create a Fake Object and Inject It"""
from src.file_uploader_dep_injection import process_file_upload
class FakeFileIOUploader:
def __init__(self):
self.uploaded_files = {}
def upload_file(self, file_path: str) -> dict:
# Simulate uploading by "saving" the file's path in a dictionary
self.uploaded_files[file_path] = f"https://file.io/fake-{file_path}"
return {"success": True, "link": self.uploaded_files[file_path]}
def test_process_file_upload_with_fake():
fake_uploader = FakeFileIOUploader()
result = process_file_upload("test.txt", uploader=fake_uploader)
assert result["success"] is True
assert result["link"] == "https://file.io/fake-test.txt"
assert "test.txt" in fake_uploader.uploaded_files
Pattern #6 — Use a Sandbox API
Using a Sandbox API is a realistic approach for testing external API interactions.
However, while sandbox testing is safer than hitting production, it’s generally slower than using fakes or mocks and you have to remember to clean up to avoid having tons of messy data in your sandbox.