No permita que el código de prueba se introduzca en producción

TL;DR: Evite agregar isTesting o indicadores similares.

Problemas 😔

• Abstracción con fugas
• Contaminación del código no empresarial
• Código frágil
• Comportamiento inconsistente
• Dependencias ocultas
• Depuración difícil
• Banderas booleanas
• Pruebas no confiables
• Código dependiente de la producción

Soluciones 😃

1. Eliminar comportamiento Ifs
2. Utilice la inyección de dependencia
3. Modela servicios externos (no te burles de ellos)
4. Configuraciones separadas
5. Aislar la lógica de prueba
6. Mantener límites de comportamiento limpios

Refactorizaciones ⚙️

Contexto 💬

Cuando agrega indicadores como isTesting , mezcla el código de prueba y producción.

Esto crea rutas ocultas que solo están activas en las pruebas.

Además, no cubre el código de producción real.

Se corre el riesgo de enviar el comportamiento de prueba a producción, lo que genera errores y un comportamiento impredecible.

Código de muestra 📖

Incorrecto ❌

 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); } }

Correcto 👉

 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); } }

Detección 🔍

• [x] Semiautomático

Puedes detectar este olor buscando indicadores condicionales como isTesting , environment == 'test' , DEBUG_MODE y modismos como estos.

Esto indica que el comportamiento de prueba se está filtrando al código de producción.

Etiquetas 🏷️

• Pruebas

Nivel 🔋

• [x] Intermedio

Por qué es importante la biyección 🗺️

Necesita una separación clara entre el código de prueba y el de producción.

Al mezclarlos, se rompe la biyección uno a uno entre el comportamiento del mundo real y el programa.

Dado que los entornos son entidades del mundo real, es necesario modelarlos explícitamente en MAPPER .

Generación IA 🤖

El código generado por IA a menudo introduce este olor cuando se utilizan trucos rápidos para realizar pruebas.

Algunas herramientas sugieren indicadores como isTesting porque priorizan la facilidad sobre el diseño adecuado.

Detección de IA 🥃

Las herramientas de IA pueden detectar este olor si las configura para marcar la lógica condicional en función de los estados de prueba.

¡Pruébalos! 🛠

Recuerde: los asistentes de IA cometen muchos errores

Indicación sugerida: elimine el método IsTesting y reemplácelo modelando los entornos

Conclusión 🏁

Evite utilizar indicadores isTesting .

Utilice la inyección de dependencia y modele los entornos para mantener separada la lógica de prueba y producción.

Relaciones 👩‍❤️‍💋‍👨

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

Aviso legal 📘

Los olores del código son mi opinión .

Créditos 🙏

Foto de Christian Gertenbach en Unsplash

Cuando se agregan indicadores de prueba, se socava la confianza en la producción.

Barrio Cunningham

Este artículo es parte de la serie CodeSmell.