Ganancias:
- Capacidad para evitar que la inteligencia artificial acepte un comportamiento erróneo como "correcto" calculando el valor esperado en pruebas unitarias independientemente de la regla de aceptación.
- Capacidad para imprimir pruebas rápidas, independientes y repetibles aplicando los principios AAA y FIRST y burlándose de las dependencias externas.
- Capacidad para probar pruebas con mutación (descifrado de código) y reconocer código difícil de probar como un olor de diseño.
La capa más grande y más rápida de la pirámide de pruebas son las pruebas unitarias: pruebas que verifican una función o un pequeño fragmento de código de forma aislada de todo lo demás. Miles de pruebas unitarias se ejecutan en segundos y detectan un error mientras el código aún está en la pantalla del desarrollador. La inteligencia artificial (IA) es quizás la más competente en la producción de pruebas unitarias: le asignas una función, la IA produce docenas de pruebas. Pero esta misma conveniencia da lugar a la trampa más grande: la IA produce fácilmente pruebas que "brillan en verde pero no verifican nada" o aceptan el comportamiento actual (quizás defectuoso) del código como "correcto". En esta unidad aprenderá cómo escribir pruebas unitarias verdaderamente protectoras con IA y la relación entre el código comprobable y la IA.
Cualidades de una buena prueba unitaria: PRIMERO
Las buenas pruebas unitarias siguen los PRIMEROS principios: rápidas, independientes (las pruebas no deben depender entre sí), repetibles (repetibles: el mismo resultado en cualquier entorno), autovalidantes (claro aprobado/reprobado), oportunas (a tiempo). Recuerde estos principios cuando haga que la IA produzca pruebas; Solicite específicamente que la prueba no dependa del mundo exterior (base de datos real, red, reloj) para que sea "independiente" y "repetible".
Patrón AAA y afirmación expresiva.
Una prueba unitaria sólida sigue la estructura AAA: Organizar (preparar – configurar entradas y dependencias), Actuar (ejecutar – llamar a la función bajo prueba), Afirmar (validar – comparar el resultado con el valor esperado). La crítica es afirmar. El error más común que comete la IA es derivar la afirmación a partir de la salida del código bajo prueba: la lógica de "lo que devuelve el código es verdadero". Esto hace que la prueba carezca de sentido. La forma correcta es determinar el valor esperado de forma independiente (a partir de los criterios de aceptación, calcularlo manualmente).
Atención: si le dice a la IA "escriba una prueba para esta función", la IA puede ejecutar la función y escribir su salida como "esperada". Esta prueba pasa incluso si la función es falsa. En su lugar, diga "usted calcula los resultados esperados de acuerdo con estas reglas, no haga referencia a la salida actual de la función".
Mocks, stubs y dependencias
Las pruebas unitarias requieren aislamiento. Si su función depende de una base de datos o API, se reemplazan con objetos simulados (simulacro/stub, un sustituto ficticio y controlado de la dependencia real) en las pruebas. Esto hace que la prueba sea rápida, independiente y reproducible. La IA puede producir una instalación simulada; Pero tenga cuidado con las burlas excesivas: si se burla de todo, la prueba sólo verificará "lo que devuelve la burla", no la lógica real. Equilibrio: emular el mundo exterior, ejecutar la lógica real bajo prueba.
Probabilidad e IA
Hay una respuesta interesante: el código que es difícil de probar suele ser un código mal diseñado. Si la IA tiene problemas para escribir pruebas para una función (demasiadas dependencias, estado global oculto, efectos secundarios), eso es un olor a diseño. Preguntarle a la IA "¿cómo refactorizarías este código para que sea comprobable?" conduce a mejores pruebas y a un mejor código.
Pruebas parametrizadas y diversidad de datos.
Escribir una prueba separada cada vez para verificar la misma regla con diferentes entradas es tedioso y difícil de mantener. Las pruebas parametrizadas (una estructura que ejecuta repetidamente la misma lógica de prueba en una lista de entradas y resultados esperados) eliminan esta repetición: un único cuerpo de prueba se alimenta con docenas de pares de entradas. La IA es muy eficiente a la hora de producir estas tablas de resultados esperados cuando le das tus reglas de aceptación; En particular, tabula sistemáticamente valores límite y clases de equivalencia.
Pero aquí también hay una trampa: la IA tiende a derivar los resultados esperados en la tabla generada a partir del código bajo prueba. Este error es aún más peligroso en las pruebas parametrizadas, porque una única lógica incorrecta invalida docenas de líneas. Por lo tanto, siempre calcule la columna de resultados esperados de forma independiente de acuerdo con la regla de aceptación y valide manualmente al menos algunas filas. Solicite también una columna de descripción "qué representa cada fila"; de modo que cuando se rompe una fila, se ve instantáneamente qué estado se rompe.
Consejo: agregue intencionalmente una "fila trampa" a la tabla de prueba parametrizada, es decir, escriba mal el resultado a sabiendas. Si esa línea no se vuelve roja cuando ejecuta la prueba, su prueba en realidad no está verificando esa situación. Esta es una verificación rápida de pase simulado.
Aviso débil / Aviso fuerte
Débil: "Escribe una prueba unitaria para esta función".
Fuerte: escriba pruebas unitarias de [lenguaje/marco] para la función "taxCalculate(monto, tasa). Regla de aceptación: resultado = monto * tasa, redondeado a 2 decimales; cantidad o tasa negativa arroja un error; devuelve 0 si la tasa es 0. Utilice la estructura AAA. Calcule manualmente los valores esperados de acuerdo con ESTAS reglas; no haga referencia a la salida actual de la función. Cubra los casos enlazados y negativos (0, negativo, muy grande, redondeado a decimales). Deje que el nombre de cada prueba describa la regla verifica. Dependencia externa "No."
Aviso potente; Proporciona la regla de aceptación, la expectativa de valor esperado independiente, la estructura y los casos extremos. Así, la prueba se convierte en la guardiana de la regla, no en el espejo del código.
Tabla de calidad de pruebas unitarias
síntoma
Mala prueba (falsa confianza)
buena prueba
afirmar
Ninguno o "no nulo"
Valor concreto esperado
Fuente de valor esperado
Salida de la función
Regla de aceptación / cálculo manual
adicción
DB real/red/hora
Aislado con simulacro/stub
caso extremo
Sólo camino feliz
límite, negativo, error
Cuando rompes el código
permanece verde
se pone rojo
Nombre
prueba1, método de prueba
describe la regla que confirma
Cuatro plantillas copiables
1) Pruebas unitarias basadas en reglas:
Su rol: ingeniero senior de pruebas de software. Escriba una prueba unitaria en la siguiente función con [idioma/marco]: [firma]. Reglas de aceptación: [reglas].- Utilice la estructura AAA.- Calcule manualmente los valores esperados de acuerdo con ESTAS reglas; NO haga referencia a la salida actual de la función. - Cubre el camino límite, negativo, error y feliz con pruebas separadas. - Deje que cada nombre de prueba describa la regla que verifica. - Simular dependencias externas; Haga que la lógica real funcione.
2) Control de la resistencia a las mutaciones:
Consulte estas pruebas unitarias. Enumere 5 ajustes menores que podría hacer al código bajo prueba (a - en lugar de +, a >= en lugar de >, un cambio de límite) y dígame para cada uno ¿CUÁL de estas pruebas se pondrá roja? Si no se devuelve ninguno, la prueba es insuficiente. Código + pruebas: [pegar]
3) Revisión de comprobabilidad:
¿Por qué es difícil escribir una prueba unitaria para esta función? Adicción oculta, estatus global, efectos secundarios, ¿hay muchas responsabilidades? Sugerir una refactorización mínima para que sea comprobable; no cambies el comportamiento. Código: [pegar]
4) Finalización incompleta del escenario:
Se proporcionan las siguientes funciones y pruebas disponibles. Enumere qué comportamiento/caso límite NUNCA se ha probado (brecha de alcance) y agregue una prueba para cada uno. Función+pruebas: [pegar]
tres mini casos
Caso 1: prueba de duplicación del código. Un desarrollador hizo que la IA escribiera una prueba para la función de redondeo; 10 pruebas fueron verdes. De hecho, la función estaba redondeando en la dirección incorrecta, pero la IA había tomado los valores esperados de la salida de la función, por lo que las pruebas consideraron el error como "verdadero". Cuando los valores esperados se calcularon manualmente con la plantilla "basada en reglas", 4 pruebas se volvieron rojas y se reveló el error real.
Caso 2: El valor del control de mutaciones. Un equipo se basó en 45 pruebas unitarias. Probé 20 ajustes menores al código con una "verificación de robustez de mutaciones"; Las pruebas detectaron sólo 11 de ellos. Las 9 interrupciones restantes transcurrieron en silencio. El equipo reforzó las pruebas débiles; Estas pruebas mejoradas detectaron un error de cálculo real en la siguiente versión.
Caso 3: La incomprobabilidad es un olor a diseño. La IA no podía escribir pruebas para una función de pedido, necesitaba constantemente la base de datos real. La plantilla de "revisión de capacidad de prueba" mostró que la función de acceso a la base de datos integrada. Cuando se eliminó la inyección de dependencia, se pudieron escribir pruebas y el código quedó más limpio.
Errores comunes
- Derivar el valor esperado del código. La IA acepta la salida de la función como "correcta"; prueba que confirma el código defectuoso.
- Prueba sin aserción o con aserción trivial. Lógica "no cometió error, pasó"; No confirma nada.
- Burla extrema. Burlándose de todo y probando sólo lo que devuelve el simulacro; La lógica real no se prueba.
- Sólo el camino feliz. Eludir estados límite, negativos y de error.
- No realizar pruebas descifrando el código. Confiar en lo verde sin comprobar si hay mutaciones.
- Haciendo caso omiso de la incomprobabilidad. No reconocer y corregir el mal diseño en lugar de impulsar pruebas exhaustivas.
En resumen
Las pruebas unitarias son la capa más grande y rápida de la pirámide de pruebas; Detecta el error en el momento más barato. La IA es muy capaz de producir pruebas unitarias, pero su mayor problema es escribir pruebas que asumen que el comportamiento incorrecto es "correcto" al derivar el valor esperado del propio código. Solución: proporcione las reglas de aceptación, calcule los valores esperados manualmente, haga cumplir los principios AAA y FIRST, burlese del mundo exterior y ejecute la lógica real, y pruebe cada prueba por mutación (rompiendo el código). El código que es difícil de probar es una señal de diseño que necesita corrección.
Tarea de aplicación
Seleccione una función que contenga una regla comercial de su propio proyecto. Escriba reglas de aceptación y haga que la IA escriba pruebas con la plantilla de “pruebas unitarias basadas en reglas”; Haga que los valores esperados se calculen manualmente. Luego aplique la “verificación de robustez de la mutación”: haga al menos 5 pequeños cortes en el código y mida cuántas pruebas se vuelven rojas. Agregue una nueva prueba para detectar corrupciones no detectadas. Informe cuántas interrupciones se detectaron (como la puntuación de mutación).
lista de verificación
- [] Di las reglas de aceptación y calculé los valores esperados manualmente.
- [] Me aseguré de que las pruebas no derivaran el valor esperado del código.
- [ ] He establecido pruebas independientes siguiendo las pautas de AAA y FIRST.
- [] Me burlé de las dependencias externas y ejecuté la lógica real.
- [] Cubrí casos límite, negativos y de error.
- [] Al descifrar el código (mutación) demostré que las pruebas efectivamente protegen.