Relaciona el veredicto de una prueba con el fallo que comprueba

Una prueba generada que pasa puede parecer tranquilizadora incluso cuando el resultado esperado procede de código defectuoso.

Una prueba comprobada con un solo programa reparado también puede juzgar mal otras implementaciones válidas, mientras que un fallo entre hilos puede permanecer oculto hasta que se produce un orden de ejecución concreto.

En tres estudios, la pregunta útil es si la comprobación estaba en condiciones de distinguir el fallo en cuestión. La evidencia procede de defectos inyectados en el código, paneles seleccionados de implementaciones y ejecuciones controladas de hilos; cada veredicto se limita a las condiciones evaluadas.

Una solicitud de cambios modifica un cálculo y una herramienta automatizada añade una prueba para las líneas editadas. La prueba se ejecuta y pasa.

Un desarrollador podría interpretar ese resultado favorable como evidencia de que el nuevo comportamiento es correcto. Sin embargo, el estudio sobre pruebas de regresión examina cambios que ya contienen defectos que la suite de pruebas existente no detectó.

En ese contexto, que una prueba generada pase solo muestra que coincide con el código modificado. El desarrollador aún necesita pruebas de que el cambio ofrece el comportamiento previsto.

Una comprobación basada en la implementación actual puede convertir un error en un resultado esperado. El estudio llama prueba que refuerza el defecto a la que pasa con código defectuoso y falla con la versión correspondiente sin ese defecto.

Una prueba así puede incorporarse al proyecto sin llamar la atención y hacer que una corrección posterior parezca una regresión. El resultado favorable inmediato oculta la pregunta práctica: ¿la comprobación puso a prueba el fallo pertinente o repitió el comportamiento que observó?

La misma pregunta aparece de otras formas. Una suite podría pasar con un programa corregido y, aun así, rechazar otra implementación que cumple el requisito.

Un defecto que involucra dos hilos de ejecución podría pasar inadvertido porque nunca se ejecutaron en el orden que lo revela. Son casos con pruebas y fallos distintos, pero cada veredicto depende de programas o ejecuciones concretos. Para interpretarlo, hay que saber qué fallo tuvo la oportunidad de distinguir la comprobación.