Tusk

Tusk leía el diff, tomaba contexto de tus tests existentes y proponía pruebas unitarias en un comentario del pull request. Ejecutaba lo que escribía y repetía las que fallaban, de modo que la salida era código ejecutable y no una sugerencia. Para un equipo que veía las pruebas como un trámite, obtener tests que funcionan sin abrir el editor era todo el valor.

Tusk Drift grababa el tráfico real contra tus endpoints y lo convertía en pruebas de API. En lugar de escribir mocks, tenías tests derivados de lo que tu servicio recibía de verdad. Eso servía para vigilar contratos, donde una respuesta que cambia en silencio rompe a clientes de los que no sabes nada hasta que alguien se queja.

CoverBot funcionaba como Dependabot, salvo que sus pull requests venían llenos de tests unitarios y no de subidas de dependencias. Lo apuntabas a un repositorio, elegías frecuencia diaria o semanal y lo dejabas correr. Tusk hablaba de un 30 % más de cobertura en un mes, una cifra de la casa que conviene leer como dirección y no como garantía.

Los tests envejecen cuando la lógica de negocio se mueve. Tusk actualizaba las suites que fallaban en cada commit para que siguieran reflejando el comportamiento actual. Es una comodidad real y un riesgo real a la vez, porque un test que se reescribe para pasar también puede reescribirse por encima de un error auténtico.

Tusk sacaba contexto de negocio de los tickets de Jira y Linear, y patrones de código de las pruebas que tu equipo ya había escrito. Los tests generados seguían tus convenciones de nombres y fixtures en lugar de inventar un estilo nuevo. Quien había probado generadores genéricos solía señalar esta diferencia como la primera que notaba.

El agente original nunca desapareció del todo. Tusk seguía revisando pull requests y podía seguir el rastro de un error reportado hasta el arreglo. La revisión venía con la misma advertencia que los tests: todo lo generado necesita una lectura humana antes de fusionarse.