Genera tests unitarios con Grok: prompt engineering para código robusto

Mira, colega, no te voy a vender humo. Generar tests unitarios es un coñazo, pero necesario. Y aquí es donde Grok brilla si sabes pedírselo bien. No es magia, es prompt engineering. Te voy a dar los prompts que uso yo, sin teoría rara, directo al código.

El prompt base: que te dé la estructura

Lo primero, define el contexto. Grok no adivina, hay que darle el mapa. Un prompt así, simple pero efectivo:

Actúa como un ingeniero de software senior experto en testing.

Genera una suite de tests unitarios para el siguiente código en [lenguaje].

Incluye: casos felices, casos borde (edge cases) y casos de error.

Usa el framework [Jest/Pytest/JUnit].

Formato de salida: solo código, sin explicaciones.

[CÓDIGO A TESTEAR]

Con esto ya tienes el 80% del trabajo. Pero ojo, Grok necesita saber qué quieres cubrir. Si no especificas, te hará tests genéricos que no aportan.

El prompt para casos borde: donde se rompe todo

Los tests que valen son los que rompen el código. Aquí tienes el prompt que uso para sacar los casos raros:

Para el siguiente código, genera tests unitarios enfocados en casos límite:

entradas vacías, valores negativos, números extremos, null/undefined,

tipos de datos incorrectos y condiciones de carrera si aplica.

Nombra cada test describiendo claramente el escenario que cubre.

[CÓDIGO]

¿Ves la diferencia? No pides "tests", pides "casos límite". Eso cambia todo. Grok se pone en modo destructivo y busca dónde tu código va a explotar.

El prompt para mocks: cuando el código depende de otros

Aquí está el truco que pocos te cuentan. Los mocks son la parte más tediosa, pero con el prompt correcto, Grok te los genera sin llorar:

Genera mocks para las dependencias externas del siguiente código.

Quiero simular: respuestas HTTP, llamadas a base de datos, y servicios de terceros.

Crea los mocks con [Mockito/Unittest.mock/Moq], y luego escribe tests que

verifiquen que el código maneja correctamente: timeout, error 500, respuesta vacía

y latencia alta. Añade assertions sobre las llamadas realizadas a los mocks.

[CÓDIGO]

Mira, esto es oro puro. No solo te crea los mocks, sino que te verifica que tu código reacciona bien cuando el mundo exterior falla. Que es justo donde la mayoría de los tests caseros se olvidan.

El prompt para cobertura total

Si quieres parecer profesional, pide cobertura de ramas, no de líneas:

Quiero una suite de tests con cobertura de ramas (branch coverage) superior al 90%

para este código. Genera los tests y luego indica qué líneas o condiciones

quedan sin cubrir y cómo llegar a ellas.

[CÓDIGO]

Grok te va a marcar los caminos que no estás probando. Es como tener un colega que te dice "esto no lo has mirado, tío". Y lo mejor, te sugiere cómo cubrirlo.

El prompt para tests de integración

Último truco. Los tests unitarios están bien, pero el infierno está en la integración:

Convierte estos tests unitarios en tests de integración para el siguiente

escenario: [describir el flujo completo]. Mantén los tests unitarios tal cual,

pero añade una capa de tests que prueben la interacción entre los módulos

A, B y C. Usa una base de datos de prueba en memoria y datos fake realistas.

[DESCRIPCIÓN DEL FLUJO O CÓDIGO]

Así pasas de "mi código funciona solo" a "mi sistema funciona junto". Que es lo que de verdad importa cuando desplegas.

Mi opinión, sin filtros

Grok no te va a escribir los tests perfectos a la primera. El primer intento siempre es regular. Pero aquí está el truco: iterar. Pídele que revise, que mejore, que sea más estricto. Trátalo como un junior con mucho potencial, no como un oráculo.

Y una cosa más, colega: revisa los tests generados. No los copies a ciegas. Grok puede tener alucinaciones y crear tests que no testean nada o que son falsos positivos. Tu criterio sigue siendo necesario.

Y tú, ¿qué usas para generar tus tests unitarios? ¿Grok, Copilot, o sigues a lo old school escribiéndolos a mano? Cuéntame en los comentarios.