Tu código refactorizado no sirve de nada sin tests

Hace poco compartí cómo creé el Refactoring Toolkit, un par de Agent Skills open source que auditan y refactorizan cualquier proyecto web sin importar el stack. La respuesta fue buena, pero una pregunta se repetía: «OK, refactoricé mi código, ¿y ahora cómo sé que no rompí nada?»

La respuesta corta: tests. La respuesta real: una estrategia de testing.

Como saber que testear

Si buscas «cómo escribir unit tests» vas a encontrar miles de tutoriales. Patrón AAA, Jest, Vitest, pytest, JUnit , la sintaxis está documentada hasta el cansancio. Pero la pregunta que realmente importa no es cómo escribir un test, sino qué debería testear, con qué tipo de test, y en qué orden de prioridad.

Y cuando construyes con IA, esta pregunta se vuelve todavía más importante. El agente te genera funciones, handlers, componentes, validaciones, todo funciona, todo se ve bien. Pero ¿realmente funciona bajo todas las condiciones? ¿Qué pasa con inputs inválidos? ¿Qué pasa cuando la base de datos no responde? ¿Qué pasa cuando un usuario no autenticado intenta acceder a una ruta protegida?

Sin tests, cada deploy es un acto de fe.

Dónde encajan las pruebas en el proceso

Cuando trabajo en un proyecto web con IA, sigo un flujo que he ido refinando:

1. Desarrollo — Construir las funcionalidades con el agente de IA
2. Auditoría — Pasar el código por una auditoría de refactorización (aquí entra el Refactoring Toolkit)
3. Refactorización — Ejecutar las correcciones priorizadas
4. Testing — Definir y ejecutar la estrategia de pruebas
5. Deploy — Ir a producción con confianza

El error más común es saltar del paso 1 directo al 5. El segundo error más común es saltar del paso 3 al 5. Las pruebas son el paso que valida que todo lo anterior realmente funciona.

La pirámide de testing

Uno de los conceptos más importantes que incorporé en la skill es la pirámide de testing. No es nueva (existe desde hace años) pero sorprende cuántos proyectos la ignoran.

La idea es simple: necesitas muchos tests rápidos y baratos en la base (unit tests), menos tests de integración en el medio, y muy pocos tests end-to-end en la punta. La razón es económica: un unit test se ejecuta en milisegundos y te dice exactamente dónde está el bug. Un E2E test tarda minutos, es frágil, y cuando falla tienes que investigar toda la cadena para encontrar el problema.

Pero lo que hace diferente a esta skill es que la pirámide no es fija. Un proyecto que es puro API backend necesita más tests de integración que de componentes. Un SPA que consume una API externa necesita más tests de componentes que de integración. La skill adapta los ratios al tipo de proyecto que estás construyendo.

Qué aprendí analizando 7 skills de testing

Antes de crear la mía, estudié 7 skills de testing existentes en la comunidad. Skills para Jest, Vitest, pytest, JUnit, Bean Validation, todas bien hechas, pero todas respondían la misma pregunta: cómo escribir tests en un framework específico.

Ninguna respondía: qué testear primero, por qué, y con qué tipo de test.

Eso es como tener un martillo perfecto sin saber qué clavo golpear. Las skills existentes son herramientas excelentes. pero a muchas lo que les falta es crear la estrategia en como deben ser orquestadas por el Agente de IA.

De ese análisis salieron los principios que guían la skill:

Prioridad por riesgo, no por facilidad. Es tentador empezar testeando las funciones puras y sencillas. Pero el mayor valor está en testear primero la autenticación, las mutaciones de datos, y la validación de inputs, ahí es donde los bugs causan daño real.

Comportamiento sobre implementación. Si refactorizas una función y los tests se rompen aunque el resultado sea el mismo, los tests están mal. Esto lo vi en varias de las skills que analicé: fomentaban assertions sobre detalles internos en vez de sobre el resultado observable.

El mocking tiene niveles. No todo merece un mock completo. A veces un stub es suficiente, a veces un fake es mejor, y a veces la mejor decisión es no mockear y dejar que el código real se ejecute. El over-mocking es uno de los anti-patrones más peligrosos porque te da tests que pasan con código roto.

La skill en acción

La Testing Strategy skill funciona en dos modos. En modo estrategia, analiza tu proyecto y produce un documento que incluye: stack detectado, evaluación de cobertura actual, pirámide recomendada con ratios, plan priorizado de qué testear y con qué tipo de test, recomendaciones de mocking, y los 5 quick wins, los tests de mayor impacto que puedes escribir primero.

En modo generación, cuando le pides que escriba los tests, lo hace siguiendo la estrategia que ya definió. Respeta las convenciones del proyecto, usa el framework de testing que ya tienes instalado, y aplica el patrón AAA en cada test.

Es agnóstica al stack. Funciona igual si usas Next.js con Jest, Django con pytest, Laravel con PHPUnit, o Rails con RSpec. No te dice cómo usar tu framework , te dice qué testear con él.

El ecosistema: skills que se complementan

Lo interesante es cómo esta skill encaja con el Refactoring Toolkit que publiqué tiempo antes. El flujo completo sería:

1. refactoring-audit audita tu código y encuentra problemas
2. refactoring-execute los corrige de forma priorizada
3. testing-strategy define qué tests necesitas y los genera

Cada skill tiene su responsabilidad clara y sus propios permisos. La de auditoría solo lee. La de ejecución modifica con tu confirmación. La de testing crea archivos nuevos. Juntas cubren el ciclo completo de calidad de código.

Y esa es la belleza de las Agent Skills como estándar abierto: puedes instalar solo las que necesitas, combinarlas con skills de otros autores, y todo funciona porque sigue la misma especificación.

Cómo instalarlo

npx skills add magallon/testing-toolkit --all

O si solo quieres la skill de estrategia:

npx skills add magallon/testing-toolkit --skill testing-strategy

Funciona con Claude Code, Cursor, Windsurf, Codex y más de 30 agentes compatibles.

El repositorio está en GitHub: github.com/magallon/testing-toolkit

Construir con IA nos da una velocidad increíble. Refactorizar nos da código limpio. Pero sin tests, no tenemos manera de probar que nada de eso funciona como esperamos. La refactorización y el testing no son pasos separados, son dos caras de la misma moneda. Uno limpia el código, el otro demuestra que sigue funcionando. Si estás construyendo proyectos serios con IA, ambos deberían ser parte de tu proceso antes de pensar en producción.