Don’t let test code sneak into production TL;DR: Avoid adding isTesting or similar flags. Problems 😔 Leaky abstraction
Non-Business code pollution
Fragile Code
Inconsistent behavior
Hidden dependencies
Difficult debugging
Boolean flags
Untrusted tests
Production dependant code Solutions 😃 Remove behavior Ifs
Use dependency injection
Model external services (Don't mock them)
Separate configurations
Isolate test logic
Maintain clean behavior boundaries Refactorings ⚙️ https://hackernoon.com/refactoring-014-how-to-remove-if?embedable=true Context 💬 When you add flags like isTesting, you mix testing and production code. This creates hidden paths that are only active in tests. Also, you don't cover real production code. You risk shipping testing behavior to production, leading to bugs and unpredictable behavior. Sample Code 📖 Wrong ❌ struct PaymentService {
    is_testing: bool,
}

impl PaymentService {
    fn process_payment(&self, amount: f64) {
        if self.is_testing {
            println!("Testing mode: Skipping real payment");
            return;
        }
        println!("Processing payment of ${}", amount);
    }
} Right 👉 trait PaymentProcessor {
    fn process(&self, amount: f64);
}

struct RealPaymentProcessor;
impl PaymentProcessor for RealPaymentProcessor {
    fn process(&self, amount: f64) {
        println!("Processing payment of ${}", amount);
    }
}

struct TestingPaymentProcessor;
impl PaymentProcessor for TestingPaymentProcessor {
    // Notice this is not a mock
    fn process(&self, _: f64) {
        println!("No payment: Skipping real transaction");
    }
}

struct PaymentService<T: PaymentProcessor> {
    processor: T,
}

impl<T: PaymentProcessor> PaymentService<T> {
    fn process_payment(&self, amount: f64) {
        self.processor.process(amount);
    }
} Detection 🔍 [x]Semi-Automatic You can detect this smell by looking for conditional flags like isTesting, environment == 'test', DEBUG_MODE, and idioms like these. These indicate that testing behavior is leaking into the production code. Tags 🏷️ Testing Level 🔋 [x]Intermediate Why the Bijection Is Important 🗺️ You need a clear separation between test and production code. When you mix them, you break the one-to-one Bijection between real-world behavior and the program. Since environments are real-world entities you need to explicitly model them in the MAPPER. AI Generation 🤖 AI-generated code often introduces this smell when you use quick hacks for testing. Some tools suggest flags like isTesting because they prioritize ease over proper design. AI Detection 🥃 AI tools can catch this smell if you configure them to flag conditional logic based on testing states. Try Them! 🛠 Remember: AI Assistants make lots of mistakes Suggested Prompt: Remove IsTesting method and replace it by modeling the environments Without Proper Instructions

With Specific Instructions



ChatGPT

ChatGPT



Claude

Claude



Perplexity

Perplexity



Copilot

Copilot



Gemini

Gemini



DeepSeek

DeepSeek



Meta AI

Meta AI



Qwen

Qwen Conclusion 🏁 Avoid using isTesting flags. Use dependency injection and model the environments to keep test and production logic separate. Relations 👩‍❤️‍💋‍👨 https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxii https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiii https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-vi-cmj31om https://hackernoon.com/code-smell-242-zombie-feature-flags?embedable=true Disclaimer 📘 Code Smells are my opinion. Credits 🙏 Photo by Christian Gertenbach on Unsplash When you add testing flags, you undermine confidence in production. Ward Cunningham 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 Don’t let test code sneak into production Don’t let test code sneak into production TL;DR: Avoid adding isTesting or similar flags. TL;DR: Avoid adding isTesting or similar flags. isTesting Problems 😔 Leaky abstraction Non-Business code pollution Fragile Code Inconsistent behavior Hidden dependencies Difficult debugging Boolean flags Untrusted tests Production dependant code Leaky abstraction Non-Business code pollution Fragile Code Inconsistent behavior Hidden dependencies Difficult debugging Boolean flags Boolean flags Untrusted tests Production dependant code Production dependant code Solutions 😃 Remove behavior Ifs Use dependency injection Model external services (Don't mock them) Separate configurations Isolate test logic Maintain clean behavior boundaries Remove behavior Ifs behavior Ifs Use dependency injection Model external services (Don't mock them) mock Separate configurations Isolate test logic Maintain clean behavior boundaries Refactorings ⚙️ https://hackernoon.com/refactoring-014-how-to-remove-if?embedable=true https://hackernoon.com/refactoring-014-how-to-remove-if?embedable=true Context 💬 When you add flags like isTesting , you mix testing and production code. isTesting This creates hidden paths that are only active in tests. Also, you don't cover real production code. You risk shipping testing behavior to production, leading to bugs and unpredictable behavior. Sample Code 📖 Wrong ❌ struct PaymentService {
    is_testing: bool,
}

impl PaymentService {
    fn process_payment(&self, amount: f64) {
        if self.is_testing {
            println!("Testing mode: Skipping real payment");
            return;
        }
        println!("Processing payment of ${}", amount);
    }
} struct PaymentService {
    is_testing: bool,
}

impl PaymentService {
    fn process_payment(&self, amount: f64) {
        if self.is_testing {
            println!("Testing mode: Skipping real payment");
            return;
        }
        println!("Processing payment of ${}", amount);
    }
} Right 👉 trait PaymentProcessor {
    fn process(&self, amount: f64);
}

struct RealPaymentProcessor;
impl PaymentProcessor for RealPaymentProcessor {
    fn process(&self, amount: f64) {
        println!("Processing payment of ${}", amount);
    }
}

struct TestingPaymentProcessor;
impl PaymentProcessor for TestingPaymentProcessor {
    // Notice this is not a mock
    fn process(&self, _: f64) {
        println!("No payment: Skipping real transaction");
    }
}

struct PaymentService<T: PaymentProcessor> {
    processor: T,
}

impl<T: PaymentProcessor> PaymentService<T> {
    fn process_payment(&self, amount: f64) {
        self.processor.process(amount);
    }
} trait PaymentProcessor {
    fn process(&self, amount: f64);
}

struct RealPaymentProcessor;
impl PaymentProcessor for RealPaymentProcessor {
    fn process(&self, amount: f64) {
        println!("Processing payment of ${}", amount);
    }
}

struct TestingPaymentProcessor;
impl PaymentProcessor for TestingPaymentProcessor {
    // Notice this is not a mock
    fn process(&self, _: f64) {
        println!("No payment: Skipping real transaction");
    }
}

struct PaymentService<T: PaymentProcessor> {
    processor: T,
}

impl<T: PaymentProcessor> PaymentService<T> {
    fn process_payment(&self, amount: f64) {
        self.processor.process(amount);
    }
} Detection 🔍 [x]Semi-Automatic [x] Semi-Automatic [x] You can detect this smell by looking for conditional flags like isTesting , environment == 'test' , DEBUG_MODE , and idioms like these. isTesting environment == 'test' DEBUG_MODE These indicate that testing behavior is leaking into the production code. Tags 🏷️ Testing Testing Level 🔋 [x]Intermediate [x] Intermediate [x] Why the Bijection Is Important 🗺️ You need a clear separation between test and production code. When you mix them, you break the one-to-one Bijection between real-world behavior and the program. Bijection Since environments are real-world entities you need to explicitly model them in the MAPPER . MAPPER AI Generation 🤖 AI-generated code often introduces this smell when you use quick hacks for testing. Some tools suggest flags like isTesting because they prioritize ease over proper design. isTesting AI Detection 🥃 AI tools can catch this smell if you configure them to flag conditional logic based on testing states. Try Them! 🛠 Remember: AI Assistants make lots of mistakes Remember: AI Assistants make lots of mistakes Suggested Prompt: Remove IsTesting method and replace it by modeling the environments Suggested Prompt: Remove IsTesting method and replace it by modeling the environments Without Proper Instructions

With Specific Instructions



ChatGPT

ChatGPT



Claude

Claude



Perplexity

Perplexity



Copilot

Copilot



Gemini

Gemini



DeepSeek

DeepSeek



Meta AI

Meta AI



Qwen

Qwen Without Proper Instructions

With Specific Instructions ChatGPT

ChatGPT Claude

Claude Perplexity

Perplexity Copilot

Copilot Gemini

Gemini DeepSeek

DeepSeek Meta AI

Meta AI 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 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 Qwen Qwen Qwen Qwen Qwen Qwen Qwen Qwen Conclusion 🏁 Avoid using isTesting flags. isTesting Use dependency injection and model the environments to keep test and production logic separate. Relations 👩‍❤️‍💋‍👨 https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxii https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxii https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiii https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiii https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-vi-cmj31om https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-vi-cmj31om https://hackernoon.com/code-smell-242-zombie-feature-flags?embedable=true https://hackernoon.com/code-smell-242-zombie-feature-flags?embedable=true Disclaimer 📘 Code Smells are my opinion . opinion Credits 🙏 Photo by Christian Gertenbach on Unsplash Christian Gertenbach Unsplash When you add testing flags, you undermine confidence in production. When you add testing flags, you undermine confidence in production. Ward Cunningham Ward Cunningham 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

Notice

Unsplash

Refactoring 024 - Replace Global Variables with Dependency Injection

Code Smell 292 - Missing Return

Buy My Book

Share your ideas with me!

Read My Stories

Buy Me a Coffee

Too Long; Didn't Read

Make resilience your competitive advantage

Code Smell 293 - You Should Avoid Adding isTesting or Similar Flags

Code Smell 293 - You Should Avoid Adding isTesting or Similar Flags

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

10 Predictions About the Future of Finance

Code Smell 290 - Refused Bequest

106 Stories To Learn About Clean Code

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

110 Stories To Learn About Refactoring

10 Predictions About the Future of Finance

Code Smell 290 - Refused Bequest

106 Stories To Learn About Clean Code

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

110 Stories To Learn About Refactoring

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps