TL;DR: You put multiple assertions in one test, making failures hard to analyze.
Problems 😔
Solutions 😃
- Follow the One-assert-per-test rule
- Extract assert methods
- Use descriptive test names
- Group related checks
- Refactor test logic in smaller pieces
Refactorings ⚙️
Context 💬
When you cram multiple assertions in a single test, failures become ambiguous.
You don’t know which part of the code caused the failure.
Imagine a test with five assertions fails at the second one - you never see whether assertions 3, 4, and 5 would have passed or failed, hiding additional defects.
Tests should be precise, easy to understand, and focused.
Each test should validate a single behavior and clearly communicate its purpose.
A single test function should test a single real world thing/concept.
You should not write long functions testing unrelated behaviors sequentially.
This usually hides the problem of heavy and coupled setups-
Sample Code 📖
Wrong ❌
def test_car_performance():
car = Formula1Car("Red Bull")
car.set_speed(320)
assert car.speed == 320
car.accelerate(10)
assert car.speed == 330
car.brake(50)
assert car.speed == 280
car.change_tire("soft")
assert car.tire == "soft"
Right 👉
def test_set_speed():
car = Formula1Car("Red Bull")
car.set_speed(320)
assert car.speed == 320, (
f"Expected speed to be 320 km/h, "
f"but got {car.speed} km/h"
)
def test_accelerate():
car = Formula1Car("Red Bull")
car.set_speed(320)
car.accelerate(10)
assert car.speed == 330, (
f"Expected speed to be 330 km/h "
f"after accelerating by 10, "
f"but got {car.speed} km/h"
)
def test_brake():
car = Formula1Car("Red Bull")
car.set_speed(330)
car.brake(50)
assert car.speed == 280, (
f"Expected speed to be 280 km/h "
f"after braking by 50, "
f"but got {car.speed} km/h"
)
def test_change_tire():
car = Formula1Car("Red Bull")
car.change_tire("soft")
assert car.tire == "soft", (
f"Expected tire type to be 'soft', "
f"but got '{car.tire}'"
)
Detection 🔍
[X] Automatic
Check for tests with more than one assert.
Look for tests that fail for multiple reasons or cover multiple unrelated actions.
Most linters and test frameworks can flag multiple assertions.
Set up a rule to warn when tests exceed one or two assertions.
Exceptions 🛑
You can group multiple asserts only when they validate the same logical behavior or output of a pure function.
Level 🔋
[X] Intermediate
Why the Bijection Is Important 🗺️
You need a bijection between MAPPER
entities and your tests.
If one test checks multiple behaviors, failures break this mapping.
When a test fails, you should immediately know exactly which behavior is broken without reading the test code.
AI Generation 🤖
AI generators often produce tests with multiple asserts, trying to cover everything in one shot.
This happens because AI tools optimize for code coverage rather than test clarity, treating tests as checklists rather than behavior specifications.
AI Detection 🧲
AI can refactor tests to keep one assert per test.
Try Them! 🛠
Remember: AI Assistants make lots of mistakes
Suggested Prompt: Refactor this test file to contain one assert per test method. Keep each test focused and descriptive.
Conclusion 🏁
Tests should be focused and precise.
You need to understand quickly which contract is broken.
Avoid multiple asserts per test to make failures clear, debugging faster, and your test suite maintainable.
Relations 👩❤️💋👨
Disclaimer 📘
Code Smells are my opinion.
Credits 🙏
Photo by Abhinand Venugopal on Unsplash
Testing is not about finding bugs, it's about understanding them
Brian Marick
This article is part of the CodeSmell Series.
