Conjunto de pruebas ciego
La suite es evidencia independiente derivada del contrato, no la definición de conformidad, por lo que una prueba fallida indica que la implementación o la prueba están mal, nunca el contrato.
test-writer decide la forma de cada prueba y test-oracle-reviewer qué cuenta como un valor independiente; este skill es el aislamiento que los rodea.
Lo que ve el autor
El archivo del contrato, la interfaz contra la que está escrito (el crate o módulo del contrato, sus tipos y documentación), y las fuentes publicadas: especificaciones, vectores proporcionados, capturas. No una implementación, una implementación anterior, o la solicitud de extracción que produjo el contrato, porque cada una lleva consigo una lectura del contrato que la suite confirmaría en lugar de probar. Cuando existe una implementación, el autor es un contexto nuevo en un árbol de trabajo en un commit sin ella; una lista de no lectura complementa eso y no lo reemplaza, ya que un contexto que ha visto la implementación no puede dejar de verla.
Valores esperados
De una fuente publicada citada en la prueba, una propiedad que el contrato establece, o una derivación cuyo método el contrato o estándar citado fija, registrado junto al vector para que un revisor pueda repetirlo; nunca de un cálculo que solo una implementación del contrato podría realizar, porque verificar dicho valor significa implementar el contrato nuevamente. Un vector derivado da cuenta de cada campo acoplado que el cambio toca: longitud, suma de verificación, firma; o su resultado no es lo que la derivación afirma. Cuando no existe una respuesta publicada, compara los resultados entre implementaciones; una verificación diferencial nunca se sostiene por sí sola, porque un error compartido por ambas la supera. Una entrada negativa escrita a mano difiere de un control independientemente válido solo en la dimensión objetivo, de modo que la prueba solo puede fallar por la razón que nombra; una regla que nombra una entrada rechazada recibe una, ya que tal regla probada solo por aceptación se cumple al aceptar todo. Las fuentes proporcionadas mantienen registrados origen, versión y suma de verificación, se toman completas o se cortan en sus propios límites de sección, y nunca se editan, porque un vector editado o recortado pierde la procedencia que lo convierte en un oráculo. Mantén un registro de cobertura junto a la suite: qué prueba verifica cada cláusula, qué cláusulas se verifican solo mediante revisión, y los límices deliberadamente no verificados, para que el silencio no se tome como cobertura.
Revisión y fusión
El revisor ejecuta test-reviewer y verifica el contrato contra el registro de cobertura en ambos sentidos: cada cláusula tiene una prueba o un vacío registrado, cada prueba cita su cláusula.
Escribe la suite antes de la implementación; fúndela una vez que una implementación la ejecute en verde, para que una prueba que ninguna implementación conforme pueda superar se encuentre antes de que vincule a todas las posteriores.
Solo lectura durante la implementación
Una solicitud de extracción de implementación nunca edita la suite ni el contrato. Una prueba que parece incorrecta, o una cláusula sin prueba, se escala con el vector o cláusula, los valores esperados y observados, y la fuente citada. La corrección va a la solicitud de extracción que posee la suite (la abierta a través de su líder, o una nueva una vez que se haya fusionado) por un autor nuevo con las mismas entradas, que recibe la decisión y no el resultado de la implementación, para que la suite permanezca ciega.