Usa las pruebas como evidencia

Empieza por el requisito

Las pruebas aportan evidencia para afirmaciones concretas. Una ejecución satisfactoria no demuestra todas las propiedades del software. Antes de pedir pruebas, identifica el comportamiento relevante y el defecto que debe detectar cada comprobación.

Para una exportación ficticia de una organización, el requisito principal es el aislamiento de datos. Un usuario de la organización A no debe recibir registros de la organización B. Una prueba que solo comprueba una descarga satisfactoria no demuestra este requisito.

Pide al agente que explique la relación entre el requisito y la aserción. Así resulta más fácil detectar casos ausentes antes de que crezca el conjunto de pruebas.

Selecciona el alcance adecuado de la prueba

Una prueba unitaria puede comprobar rápidamente una transformación pequeña. Una prueba de integración puede comprobar cómo trabajan juntos varios componentes. Una prueba de extremo a extremo puede comprobar una secuencia importante del usuario en la aplicación desplegada o en una versión representativa.

Usa el alcance más reducido que aporte la evidencia necesaria. Un formateador no necesita una prueba completa de navegador para cada entrada. Un límite de autorización puede requerir una ruta real y un recorrido de acceso a datos. Una interacción crítica del navegador necesita pruebas sobre la interfaz renderizada.

No existe un porcentaje fijo de tipos de prueba que sirva para todos los sistemas. Elige según el fallo que debas detectar y el coste de mantener la comprobación.

Evita compartir un supuesto incorrecto

Un agente puede escribir la implementación y las pruebas a partir del mismo malentendido. Ambas pueden coincidir sin cumplir el requisito.

Supongamos que la implementación filtra registros por el identificador de organización enviado en la solicitud. La prueba usa el mismo identificador para el usuario autenticado y para la solicitud. Pasa. Falta el caso de un usuario que solicita el identificador de otra organización.

Añade ese caso usando la identidad real de confianza y el recorrido de autorización. Un mock que siempre devuelve «permitido» no puede demostrar el aislamiento entre tenants. Solo demuestra el comportamiento después de que la autorización permita el acceso.

Verifica que la prueba pueda fallar

Para un defecto conocido, ejecuta la nueva prueba de regresión contra la versión defectuosa en una rama aislada. Confirma que falla por el motivo previsto. Después, aplica la corrección y vuelve a ejecutarla.

Una prueba que falla porque no puede cargar sus datos de prueba todavía no aporta evidencia sobre el comportamiento de negocio. Inspecciona el fallo, no solo el código de salida.

Para cambios más amplios, las pruebas de mutación pueden ayudar a evaluar si determinados cambios de código provocan fallos en las pruebas. Tienen un coste y no sustituyen a la revisión de requisitos. Úsalas cuando esa evidencia adicional ayude a tomar una decisión importante.

Mantén la evidencia vinculada al cambio

Ejecuta las comprobaciones pertinentes sobre la versión final. Registra las omitidas y sus motivos. El resultado de un commit anterior puede dejar de ser válido después de una corrección de revisión.

Mantén comprensibles las pruebas. Prefiere una preparación y una aserción explícitas a una gran función auxiliar que oculte la condición importante. Elimina comprobaciones redundantes cuando añadan mantenimiento sin detectar un fallo distinto.

Quien revise debe poder explicar qué demuestran las pruebas y qué sigue siendo incierto. Esa explicación es más útil que un gran número de pruebas.