No permita que el código de prueba se introduzca en producción  TL;DR: Evite agregar   o indicadores similares. isTesting  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   de ellos) te burles  Configuraciones separadas  Aislar la lógica de prueba  Mantener límites de comportamiento limpios  Refactorizaciones ⚙️   https://hackernoon.com/refactoring-014-how-to-remove-if?embedable=true  Contexto 💬  Cuando agrega indicadores como   , mezcla el código de prueba y producción. isTesting  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 🔍    Semiautomático [x]  Puedes detectar este olor buscando indicadores condicionales como   ,   ,   y modismos como estos. isTesting environment == 'test' DEBUG_MODE  Esto indica que el comportamiento de prueba se está filtrando al código de producción.  Etiquetas 🏷️  Pruebas  Nivel 🔋    Intermedio [x]  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   uno a uno entre el comportamiento del mundo real y el programa. biyección  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   porque priorizan la facilidad sobre el diseño adecuado. isTesting  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   ChatGPT   ChatGPT   Claudio   Claudio   Perplejidad   Perplejidad   Copiloto   Copiloto   Géminis   Géminis   Búsqueda profunda   Búsqueda profunda   Meta IA   Meta IA   Qwen   Qwen  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   https://hackernoon.com/code-smell-242-zombie-feature-flags?embedable=true  Aviso legal 📘  Los olores del código son mi   . opinión  Créditos 🙏  Foto de   en  Christian Gertenbach Unsplash  Cuando se agregan indicadores de prueba, se socava la confianza en la producción.   Barrio Cunningham   https://hackernoon.com/400-think-provoking-software-engineering-quotes?embedable=true  Este artículo es parte de la serie CodeSmell.   https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd?embedable=true

Winner of Noonies 2020 for the award Hacker Noon Contributor of the Year - REFACTORING.

2020 - Hacker Noon Contributor of the Year in REFACTORING

2022 - HackerNoon Contributor of the Year - Clean Code

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Github

2022 - HackerNoon Contributor of the Year - Machine Learning

2022 - HackerNoon Contributor of the Year - Quality Assurance

2022 - HackerNoon Contributor of the Year - Refactoring

2022 - HackerNoon Contributor of the Year - Software Architecture

2022 - the Greatest Storyteller

Buy My Book

Share your ideas with me!

Read My Stories

Buy Me a Coffee

Software Engineer and Book Author

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Código de error 293: debe evitar agregar isTesting o indicadores similares

Código de error 293: debe evitar agregar isTesting o indicadores similares

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Una breve introducción a la teoría del cerebro de Boltzmann

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Una breve introducción a la teoría del cerebro de Boltzmann

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps