Cluttered tests hide real problems Cluttered tests hide real problems TL;DR: You put multiple assertions in one test, making failures hard to analyze. TL;DR: You put multiple assertions in one test, making failures hard to analyze. Problems 😔 Readability
Fragile tests
Slow Tests
Debugging pain
Coupled logic
Maintenance nightmare
Ambiguous failures
Generic assertions Readability Fragile tests Fragile Slow Tests Debugging pain Coupled logic Maintenance nightmare Ambiguous failures Ambiguous failures Generic assertions Generic Solutions 😃 Follow the One-assert-per-test rule
Extract assert methods
Use descriptive test names
Group related checks
Refactor test logic in smaller pieces Follow the One-assert-per-test rule One-assert-per-test Extract assert methods Extract Use descriptive test names Group related checks Refactor test logic in smaller pieces Refactor Refactorings ⚙️ https://hackernoon.com/improving-the-code-one-line-at-a-time?embedable=true https://hackernoon.com/improving-the-code-one-line-at-a-time?embedable=true https://hackernoon.com/refactoring-013-eliminating-repeated-code-with-dry-principles?embedable=true https://hackernoon.com/refactoring-013-eliminating-repeated-code-with-dry-principles?embedable=true https://maximilianocontieri.com/refactoring-010-extract-method-object?embedable=true https://maximilianocontieri.com/refactoring-010-extract-method-object?embedable=true https://maximilianocontieri.com/refactoring-011-replace-comments-with-tests?embedable=true https://maximilianocontieri.com/refactoring-011-replace-comments-with-tests?embedable=true 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. coupled 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" 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}'"
    ) 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 [x]Automatic [x] 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. Tags 🏷️ Testing Testing Level 🔋 [x]Intermediate [x]Intermediate [x] Why the Bijection Is Important 🗺️ You need a bijection between MAPPER entities and your tests. bijection MAPPER 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 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. Suggested Prompt: Refactor this test file to contain one assert per test method. Keep each test focused and descriptive. Without Proper Instructions

With Specific Instructions



ChatGPT

ChatGPT



Claude

Claude



Perplexity

Perplexity



Copilot

Copilot



You

You



Gemini

Gemini



DeepSeek

DeepSeek



Meta AI

Meta AI



Grok

Grok



Qwen

Qwen Without Proper Instructions

With Specific Instructions



ChatGPT

ChatGPT



Claude

Claude



Perplexity

Perplexity



Copilot

Copilot



You

You



Gemini

Gemini



DeepSeek

DeepSeek



Meta AI

Meta AI



Grok

Grok



Qwen

Qwen Without Proper Instructions

With Specific Instructions Without Proper Instructions Without Proper Instructions With Specific Instructions With Specific Instructions ChatGPT

ChatGPT ChatGPT ChatGPT ChatGPT ChatGPT ChatGPT ChatGPT Claude

Claude Claude Claude Claude Claude Claude Claude Perplexity

Perplexity Perplexity Perplexity Perplexity Perplexity Perplexity Perplexity Copilot

Copilot Copilot Copilot Copilot Copilot Copilot Copilot You

You You You You You You You Gemini

Gemini Gemini Gemini Gemini Gemini Gemini Gemini DeepSeek

DeepSeek DeepSeek DeepSeek DeepSeek DeepSeek DeepSeek DeepSeek Meta AI

Meta AI Meta AI Meta AI Meta AI Meta AI Meta AI Meta AI Grok

Grok Grok Grok Grok Grok Grok Grok Qwen

Qwen Qwen Qwen Qwen Qwen Qwen Qwen 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 👩‍❤️‍💋‍👨 https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xi-sit35t1 https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xi-sit35t1 https://hackernoon.com/code-smell-03-functions-are-too-long-heres-how-to-fix-that https://hackernoon.com/code-smell-03-functions-are-too-long-heres-how-to-fix-that https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-x-i7r34uj https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-x-i7r34uj https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxi https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxi More Information 📕 https://hackernoon.com/coupling-the-one-and-only-software-designing-problem-9z5a321h https://hackernoon.com/coupling-the-one-and-only-software-designing-problem-9z5a321h Disclaimer 📘 Code Smells are my opinion. opinion Credits 🙏 Photo by Abhinand Venugopal on Unsplash Abhinand Venugopal Unsplash Testing is not about finding bugs, it's about understanding them Testing is not about finding bugs, it's about understanding them Brian Marick Brian Marick https://hackernoon.com/400-thought-provoking-software-engineering-quotes?embedable=true https://hackernoon.com/400-thought-provoking-software-engineering-quotes?embedable=true This article is part of the CodeSmell Series. https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd?embedable=true https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd?embedable=true

Keep

Code Smell 08 - Send Messages Only to Your Direct Acquaintances, Not Their Friends

Buy My Book

Share your ideas with me!

Code Smell 312 - You Put Multiple Assertions in One Test, Making Failures Hard to Analyze

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

10 Predictions About the Future of Finance

5 easy wins to refactor even the ugliest code

5 VERY common code smells and how to fix them

A Hacker Tried to Steal $566M by Exploiting a Code Smell, Here's How

Code Smell 240 - Dead Store Code

10 Predictions About the Future of Finance

5 easy wins to refactor even the ugliest code

5 VERY common code smells and how to fix them

A Hacker Tried to Steal $566M by Exploiting a Code Smell, Here's How

Code Smell 240 - Dead Store Code

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps