Las pruebas confusas ocultan problemas reales 
 
 TL;DR: Coloca varias afirmaciones en una sola prueba, lo que dificulta el análisis de los fallos. TL;DR: Coloca varias afirmaciones en una sola prueba, lo que dificulta el análisis de los fallos. Problemas 
 
 
 
 
 
 
 
 
 Legibilidad Pruebas frágiles Pruebas lentas Debugging de dolor Lógica conjunta Pesadilla de mantenimiento Fracasos ambiguos Afirmaciones genéricas Soluciones 
 
 
 
 
 
 Siga la regla One-Assert-per-Test Extracto de los métodos de afirmación Usar nombres de prueba descriptivos Controles relacionados con el grupo Lógica de prueba de refactor en piezas más pequeñas Recuperación ️ https://hackernoon.com/improving-the-code-one-line-at-a-time?embedable=true https://hackernoon.com/refactoring-013-eliminating-repeated-code-with-dry-principles?embedable=true https://maximilianocontieri.com/refactoring-010-extract-method-object?embedable=true https://maximilianocontieri.com/refactoring-011-replace-comments-with-tests?embedable=true Contexto Cuando se confunden varias afirmaciones en una sola prueba, los fracasos se vuelven ambiguos. No se sabe qué parte del código causó el fracaso. Imagínese que una prueba con cinco afirmaciones falla en la segunda - nunca se ve si las afirmaciones 3, 4 y 5 habrían pasado o fallado, ocultando defectos adicionales. Las pruebas deben ser precisas, fáciles de entender y enfocadas. Cada prueba debe validar un único comportamiento y comunicar claramente su propósito. Una única función de prueba debe probar una única cosa/concepto del mundo real. No debe escribir funciones largas para probar comportamientos no relacionados de forma secuencial. Esto suele ocultar el problema de las pesadas y Los setups. Conexión Código de muestreo equivocado 🙂 def test_car_performance():
    car = Formula1Car("Red Bull")
    car.set_speed(320)
    assert car.speed == 320
    car.accelerate(10)
    assert car.speed == 330
    car.brake(50)
    assert car.speed == 280
    car.change_tire("soft")
    assert car.tire == "soft"
 Derecho def test_set_speed():
    car = Formula1Car("Red Bull")
    car.set_speed(320)
    assert car.speed == 320, (
        f"Expected speed to be 320 km/h, "
        f"but got {car.speed} km/h"
    )

def test_accelerate():
    car = Formula1Car("Red Bull")
    car.set_speed(320)
    car.accelerate(10)
    assert car.speed == 330, (
        f"Expected speed to be 330 km/h "
        f"after accelerating by 10, "
        f"but got {car.speed} km/h"
    )

def test_brake():
    car = Formula1Car("Red Bull")
    car.set_speed(330)
    car.brake(50)
    assert car.speed == 280, (
        f"Expected speed to be 280 km/h "
        f"after braking by 50, "
        f"but got {car.speed} km/h"
    )

def test_change_tire():
    car = Formula1Car("Red Bull")
    car.change_tire("soft")
    assert car.tire == "soft", (
        f"Expected tire type to be 'soft', "
        f"but got '{car.tire}'"
    )
 Detección 
 
 [x] Es automático Compruebe las pruebas con más de una afirmación. Busque pruebas que fallan por múltiples razones o cubran múltiples acciones no relacionadas. La mayoría de los linterns y marcos de prueba pueden marcar múltiples afirmaciones. Establecer una regla para advertir cuando las pruebas superan una o dos afirmaciones. excepciones Puede agrupar varias afirmaciones sólo cuando validen el mismo comportamiento lógico o la salida de una función pura. Tags ️ 
 
 La prueba Nivel 
 
 [x] El Intermedio ¿Por qué es importante la bijeción ️ Necesitas una entre Entidades y sus pruebas. Bijeción Mapa Si una prueba verifica varios comportamientos, los fallos rompen este mapeo. Cuando una prueba falla, debe saber inmediatamente exactamente qué comportamiento está roto sin leer el código de prueba. La generación Los generadores de IA a menudo producen pruebas con múltiples afirmaciones, tratando de cubrir todo en un solo disparo. Esto ocurre porque las herramientas de IA se optimizan para la cobertura de código en lugar de la claridad de pruebas, tratando las pruebas como listas de verificación en lugar de especificaciones de comportamiento. Detección AI puede refactor de pruebas para mantener una afirmación por prueba. ¡Pruébelo! Recuerda: los asistentes de IA cometen muchos errores 
 
 Prompt sugerido: Refactor este archivo de prueba para contener una afirmación por método de prueba. Prompt sugerido: Refactor este archivo de prueba para contener una afirmación por método de prueba. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Without Proper Instructions 
 With Specific Instructions 
 
 
 
 ChatGPT 
 ChatGPT 
 
 
 
 Claude 
 Claude 
 
 
 
 Perplexity 
 Perplexity 
 
 
 
 Copilot 
 Copilot 
 
 
 
 You 
 You 
 
 
 
 Gemini 
 Gemini 
 
 
 
 DeepSeek 
 DeepSeek 
 
 
 
 Meta AI 
 Meta AI 
 
 
 
 Grok 
 Grok 
 
 
 
 Qwen 
 Qwen ChatGPT ChatGPT Claude Claude Perplejidad Perplejidad piloto piloto tú tú Gemini Gemini profundidad profundidad El objetivo es El objetivo es Grúas Grúas Quien Quien Conclusión Las pruebas deben ser focalizadas y precisas. Debes saber rápidamente cuál es el contrato que se rompe. Evite múltiples afirmaciones por prueba para que los errores sean claros, el desgaste sea más rápido y su suite de pruebas sea mantenible. Relaciones https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xi-sit35t1 https://hackernoon.com/code-smell-03-functions-are-too-long-heres-how-to-fix-that https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-x-i7r34uj https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxi Más información https://hackernoon.com/coupling-the-one-and-only-software-designing-problem-9z5a321h Disclaimer Los olores son míos . Opinión Créditos Fotografía por es Abhinand Venugopal Unosplash 
 
 La prueba no se trata de encontrar errores, se trata de comprenderlos La prueba no se trata de encontrar errores, se trata de comprenderlos Brian Marick https://hackernoon.com/400-thought-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 Olor 312 - Pones múltiples afirmaciones en una sola prueba, haciendo que los fracasos sean difíciles de analizar

Código Olor 312 - Pones múltiples afirmaciones en una sola prueba, haciendo que los fracasos sean difíciles de analizar

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

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

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

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

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps