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

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 😃

1. Remove behavior Ifs
2. Use dependency injection
3. Model external services (Don't mock them)
4. Separate configurations
5. Isolate test logic
6. Maintain clean behavior boundaries

Refactorings ⚙️

HACKERNOON

Refactoring 014 - How to Remove IF | HackerNoon

The first instruction you learned should be the least you use

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

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

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

This article is part of the CodeSmell Series.