Skip to main content

Command Palette

Search for a command to run...

Code Smell 293 - isTesting

Don’t let test code sneak into production

Published
β€’3 min read
Code Smell 293 - isTesting
M

I’m a senior software engineer loving clean code, and declarative designs. S.O.L.I.D. and agile methodologies fan.

TL;DR: Avoid adding isTesting or similar flags.

Problems πŸ˜”

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 βš™οΈ

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 πŸ‘©β€β€οΈβ€πŸ’‹β€πŸ‘¨

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.

Code Smells

Part 25 of 50

In this series, we will see several symptoms and situations that make us doubt the quality of our developments. We will present possible solutions. Most are just clues. They are no hard rules.

Up next

Code Smell 292 - Missing Return

When your code loses its way