Evita Utilitzar isTesting o Altres Flags Similars

No deixis que el codi de prova arribi a producció

Resum: Evita afegir flags com isTesting o similars al teu codi.

Problemes ??

• Abstracció deficient
• Contaminació amb codi no relacionat amb el negoci
• Codi fràgil
• Comportament inconsistent
• Dependències ocultes
• Dificultat en la depuració
• Us de flags booleanes
• Proves no fiables
• Codi dependent de l’entorn de producció

Solucions ??

1. Eliminar condicionants innecessaris
2. Utilitzar injecció de dependències
3. Modelar serveis externs sense usar mocks
4. Separar configuracions
5. Aïllar la lògica de prova
6. Mantenir límits de comportament ben definits

Refactorització ??

L’ús de patrons adequats permet eliminar flags innecessàries en la lògica del codi.

Context ??

Quan afegeixes flags com isTesting, barreges codi de prova i producció, creant camins ocults que només s’activen en proves. Això impedeix cobrir correctament el codi en producció i augmenta el risc d’errors.

Exemple de Codi ??

Incorrecte ?

struct PaymentService {
    is_testing: bool,
}

impl PaymentService {
    fn process_payment(&self, amount: f64) {
        if self.is_testing {
            println!('Mode de prova: Ometent pagament real');
            return;
        }
        println!('Processant pagament de ${}', amount);
    }
}

Correcte ??

trait PaymentProcessor {
    fn process(&self, amount: f64);
}

struct RealPaymentProcessor;
impl PaymentProcessor for RealPaymentProcessor {
    fn process(&self, amount: f64) {
        println!('Processant pagament de ${}', amount);
    }
}

struct TestingPaymentProcessor;
impl PaymentProcessor for TestingPaymentProcessor {
    fn process(&self, _: f64) {
        println!('No s’executa pagament: Ometent transacció real');
    }
}

struct PaymentService {
    processor: T,
}

impl PaymentService {
    fn process_payment(&self, amount: f64) {
        self.processor.process(amount);
    }
}

Detecció ??

• [x] Semi-Automàtica

Es pot detectar aquesta mala pràctica buscant flags condicionals com isTesting, environment == 'test' o DEBUG_MODE, indicis que la lògica de prova s’està filtrant a la producció.

Etiquetes ???

• Proves

Nivell ??

• [x] Intermedi

Importància de la separació d’entorns ???

És essencial mantenir una separació clara entre codi de prova i producció. Si es barregen, es trenca la correspondència entre el comportament real i el funcionament del programa.

Generació de codi per IA ??

Les eines d’IA solen introduir aquest problema en prioritzar solucions ràpides sobre un bon disseny.

Detecció d’IA ??

Si es configuren correctament, les eines de detecció poden identificar aquest problema en analitzar lògica condicional basada en estats de prova.

Conclusió ??

Evita utilitzar flags com isTesting al teu codi. En lloc d’això, aplica injecció de dependències i modela els entorns per garantir una separació clara entre la lògica de prova i producció.

En Q2BSTUDIO, una empresa especialitzada en desenvolupament i serveis tecnològics, promovem les millors pràctiques de desenvolupament per garantir codi net i mantenible. El nostre equip d’experts s’assegura d’aplicar principis sòlids d’arquitectura de programari, evitant problemes com la filtració de codi de prova en producció.