ViachaslauStrelnikau/agent-skills

Probador Java

Modelo Operativo

Añade pruebas que aumenten la confianza en el nivel más bajo práctico de la pirámide de pruebas. Prefiere muchas pruebas unitarias rápidas, menos pruebas de integración o de contrato, y un número muy pequeño de pruebas de extremo a extremo para los recorridos críticos.

Comienza leyendo el código de producción, las pruebas existentes, los archivos de construcción y las convenciones de CI. Conserva el estilo de prueba del proyecto a menos que sea claramente débil o inconsistente. No introduzcas una nueva biblioteca de pruebas cuando el proyecto ya tenga un equivalente adecuado.

Usa Context7 para la documentación actualizada antes de añadir o cambiar sintaxis, configuración, anotaciones, extensiones o versiones de dependencias específicas de bibliotecas para JUnit, Mockito, AssertJ, Spring Boot Test, Testcontainers, REST Assured, Pact, WireMock, Maven, Gradle u otras herramientas de prueba Java. Si Context7 no está disponible o no puede resolver la biblioteca, usa la documentación oficial del proyecto; no adivines detalles sensibles a la versión.

Selecciona el Modo de Tarea

• Para implementación, identifica el comportamiento modificado, añade el conjunto más pequeño útil de pruebas y verifícalas.
• Para revisión, inspecciona el conjunto existente e informa sobre corrección, cobertura de riesgos faltante, fragilidad, duplicación, problemas de aislamiento y costo de ejecución. No edites a menos que el usuario solicite cambios.
• Para depuración, reproduce la falla de manera limitada, clasifica su causa y cambia pruebas o código de producción solo dentro del alcance solicitado por el usuario.
• Para organización o planificación de CI, inventaria tipos de prueba, conjuntos de fuentes, tiempo de ejecución, dependencias y etapas actuales del pipeline antes de recomendar ubicación, selección, paralelización o almacenamiento en caché.

Flujo de Trabajo

1. Identifica el comportamiento a proteger.

   • Encuentra APIs públicas, métodos de servicio, reglas de dominio, límites de persistencia, manejadores de mensajes, controladores, programadores y rutas de error tocados por la solicitud.
   • Prefiere aserciones de comportamiento sobre aserciones de implementación.
   • Trata los métodos privados como detalles de implementación; prueba a través del comportamiento público o extrae un colaborador enfocado si la lógica privada es compleja.

2. Elige el nivel de prueba más bajo útil.

   • Usa pruebas unitarias para lógica de dominio pura, ramificaciones, validación, mapeo y orquestación de colaboradores que se puedan probar sin E/S real.
   • Usa pruebas de rebanada o integración para cableado de framework, consultas de persistencia, migraciones de datos, serialización, transacciones, enrutamiento HTTP, filtros de seguridad y adaptadores de límites externos.
   • Usa pruebas de contrato cuando un límite de servicio sea propiedad de múltiples equipos o implementables independientes.
   • Usa pruebas de extremo a extremo solo para flujos centrales que no puedan ser confiables a través de pruebas de nivel inferior.

3. Implementa cobertura enfocada.

   • Cubre caminos felices, casos límite, valores frontera, entradas no válidas, fallos, resultados de autorización de seguridad, cambios de estado de la base de datos y casos de regresión.
   • Usa pruebas parametrizadas para ejemplos repetidos de entrada/salida.
   • Mantén una razón de fallo por prueba. Nombra las pruebas por comportamiento y resultado esperado.
   • Usa datos deterministas. Evita esperas, suposiciones de tiempo de reloj, orden aleatorio, dependencias de red y estado mutable compartido.

4. Mantén las pruebas mantenibles.

   • Usa organizar/actuar/afirmar o dado/cuando/entonces de manera consistente.
   • Crea constructores, fixtures o madres de datos de prueba solo cuando la configuración repetida oculte la intención.
   • Mantén los mocks en los límites del proceso o en colaboradores genuinamente incómodos. No mockees objetos de valor, colecciones o lógica de dominio trivial.
   • Evita verificar cada interacción. Verifica los resultados primero; verifica interacciones solo cuando la interacción sea el comportamiento.

5. Verifica e informa.

   • Descubre comandos del contenedor del repositorio, módulos, plugins, conjuntos de fuentes y configuración de CI. Lee references/java-testing-tooling.md para reglas de construcción y manejo de fallos.
   • Ejecuta primero el comando de prueba relevante más estrecho, luego el conjunto más amplio si el radio de explosión lo justifica.
   • Si una prueba de nivel superior expone un error que ninguna prueba de nivel inferior detecta, añade una prueba de regresión de nivel inferior.
   • Elimina o evita comprobaciones de alto nivel duplicadas cuando las pruebas de nivel inferior ya cubran las condiciones y la prueba de alto nivel no añada confianza única.
   • Informa sobre pruebas añadidas o revisadas, comportamientos cubiertos, comandos y resultados, fallos o comprobaciones no disponibles, y riesgos restantes. Distingue nuevos fallos de fallos preexistentes o ambientales confirmados.

Referencias

Lee references/test-pyramid.md al decidir el alcance de la prueba, la ubicación en CI, la duplicación o cuántas pruebas de extremo a extremo añadir.

Lee references/java-testing-tooling.md al elegir herramientas de prueba Java, dependencias, anotaciones, estilo de mocking, forma de prueba Spring Boot, patrones Testcontainers, pruebas de API, pruebas de contrato, comandos de construcción o clasificación de fallos.