Auditoría de pruebas
Esta skill tiene dos modos:
- Autoría. La compuerta de autoría a continuación se aplica a cada prueba que agregues o cambies.
- Auditoría. Elimina pruebas de bajo valor en lotes coherentes agrupados por el propietario de la funcionalidad de producción. Nunca persigas recuentos de eliminación; el objetivo es un conjunto donde cada contrato tenga un propietario fuerte, no un número menor.
Para una campaña que pode la superficie de pruebas de un subsistema completo de una vez, lee primero CAMPAIGN.md.
Compuerta de autoría
Antes de agregar una prueba, responde estas cuatro preguntas:
- ¿Qué comportamiento observable, invariante o contrato independiente protege?
- ¿Qué regresión creíble la haría fallar?
- ¿Por qué la prueba existente no lo cubre? Cada contrato debería tener un propietario principal en el límite más fuerte. Una prueba en otra capa necesita un riesgo de transporte o ciclo de vida distinto para justificarla. Extiende tablas existentes y accesorios compartidos en lugar de agregar copias cercanas, y consolida la configuración repetida.
- ¿Necesita una exportación, bandera, envoltorio o gancho de inyección que no tiene ningún llamador en producción? Si es así, mueve la prueba al límite real.
Reglas complementarias:
- Usa la guía de límites y costos para elegir dónde vive la prueba y cuánto puede costar.
- Una prueba de regresión debe fallar antes de la corrección por la razón prevista y pasar después de la reparación. Si no puedes mostrar el fallo previo a la corrección, indícalo en tu informe.
- Una regresión en el límite propietario cubre un error. Nunca la repitas en cada capa que el error atravesó.
- Una refactorización que preserva el comportamiento no debe romper la prueba.
Patrones basura
- Rechaza autocomparaciones, inventarios copiados, búsquedas en código fuente, aserciones sobre la implementación o la forma de las llamadas, contratos duplicados, puntos de inyección solo para pruebas, valores esperados generados por el sujeto bajo prueba y simulaciones que proporcionan el comportamiento que se está afirmando.
- Los accesorios no deben fabricar recibos o ordenamientos que el propietario debería producir, y no deben reclamar persistencia a través de una ruta que el código nunca escribe.
- Un control negativo debe fallar en la guarda prevista, y el nombre de una prueba debe coincidir con el comportamiento que realmente ejercita.
- Al auditar candidatos, usa la lista de verificación completa.
Barra de retención
- Conserva las pruebas que protegen contratos independientes: API pública, SDK, protocolo, configuración, migración, almacenamiento, seguridad, plataforma, valores predeterminados, bytes de prompt, resultados generados en varios idiomas, empaquetado, publicación, arquitectura y ordenamiento observable. Ser estática o lenta no hace que una prueba sea desechable.
- La inspección del código fuente solo es aceptable cuando sobrevive a refactorizaciones solo de identificadores y protege un contrato independiente orientado al usuario.
- Una prueba base que falla puede ser un error del producto que reparar, no una prueba que eliminar.
Auditoría y validación
- Antes de cualquier edición de auditoría, lee la evidencia candidata y el flujo de trabajo. Inspecciona los propietarios, llamadores e historial completos, y registra qué evidencia permanece antes de eliminar algo.
- Elimina los puntos de inyección obsoletos junto con sus pruebas. Nunca optimices para recuentos de eliminación.
- No edites el repositorio mientras una ejecución de pruebas esté en curso. Ejecuta el comando de pruebas enfocado del proyecto para el propietario y las pruebas hermanas, ejecuta las comprobaciones de archivos modificados del proyecto y luego obtén una revisión antes de publicar.
- Informa las causas, los contratos retenidos, la evidencia y su costo, las líneas de código de producción frente a las de prueba cambiadas y los seguimientos. Confirma, empuja o publica solo cuando la tarea te dé esa autoridad.