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 😃
- Eliminar comportamiento Ifs
- Utilice la inyección de dependencia
- Modela servicios externos (no te burles de ellos)
- Configuraciones separadas
- Aislar la lógica de prueba
- 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
Sin instrucciones adecuadas | Con instrucciones específicas |
|---|---|
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.
