Estás arrancando un microservicio completamente nuevo — diseña su estrategia de testing desde cero

#La última pregunta de pizarra: diseña toda la estrategia

Esta es la pregunta que separa "sé escribir un test" de "sé darle a un equipo la confianza suficiente para lanzar un viernes". No hay un único diagrama correcto, pero sí una forma coherente de razonarlo en voz alta: arrancar desde lo que un solo commit puede probar barato, e ir hacia afuera hasta lo que solo el tráfico real, a lo largo del tiempo, puede probar del todo.

#Capa por capa

Los tests unitarios están en la base: lógica de negocio pura, aislada de la red, la base de datos y el reloj, con los colaboradores reemplazados por fakes o mocks. Corren en segundos, así que corren en cada tecla que un desarrollador quiera disparar, y en cada commit en CI. Su trabajo es angosto a propósito — atrapar un bug de lógica en el cálculo del descuento, no un bug de cableado en cómo el servicio habla con Postgres?.

Los tests de contrato vienen después: por cada frontera que este servicio tiene con el servicio de otro equipo — como consumidor de una API que llama, o como proveedor de una API que expone — un contrato dirigido por el consumidor (Pact es la herramienta habitual) captura la forma exacta de peticiones y respuestas que ambos lados acuerdan. El test de contrato del consumidor corre contra un proveedor simulado construido a partir de ese contrato; el proveedor verifica el mismo contrato contra su implementación real, ambos de forma independiente, cada uno en el CI de su propio equipo, sin entorno compartido y sin la inestabilidad de tener dos servicios desplegados al mismo tiempo. Esto es lo que permite que cien microservicios eviten necesitar un entorno de staging de cien servicios solo para atrapar un campo renombrado.

Los tests de integración vienen a continuación: aquí es donde las fronteras propias del servicio — su SQL real, su consumidor de mensajes real, su cliente de caché real — corren contra dependencias reales vía Testcontainers (un Postgres real, un broker de Kafka real, un Redis real), dentro de CI, de forma hermética, y se destruyen al terminar la corrida. Esta es la capa que atrapa "la migración no agregó el índice que la consulta necesita" o "el consumidor no maneja un mensaje envenenado", ninguno de los cuales un mock revelaría jamás.

Los tests end-to-end son deliberadamente pocos: un puñado de recorridos de usuario críticos — hacer un pedido, completar el checkout, autenticarse — ejercitados como caja negra contra un entorno de staging completamente desplegado, a través de la frontera real de HTTP o gRPC, sin simular nada internamente. Son lentos y comparativamente frágiles, así que la estrategia mantiene su número pequeño y su alcance enfocado en los caminos que serían titular de noticia si se rompieran.

Los tests de carga y rendimiento validan un eje completamente distinto: no "¿la lógica es correcta?" sino "¿el sistema cumple sus SLOs de latencia y throughput bajo carga esperada y pico, y se degrada con elegancia más allá de eso?". Son costosos de correr, así que no corren en cada commit — típicamente corren cada noche, o como condición de una rama de release, usando formas de tráfico y volúmenes de datos realistas.

El testing en producción es la capa que nunca se apaga: análisis de canary comparando las señales doradas de una nueva versión contra la línea base con un porcentaje pequeño de tráfico, feature flags controlando la exposición y dando un botón de apagado instantáneo, monitoreo sintético golpeando los endpoints de producción de forma programada para atrapar problemas entre peticiones reales de usuarios, y alertas basadas en SLO como el detector de regresión definitivo — el único chequeo que sigue corriendo seis meses después de que el código se lanzó, cuando ya nadie lo está mirando.

#Qué corre dónde

#Uniendo todo

#Propiedad y datos de prueba

Nada de esto funciona si es trabajo de un solo equipo. Los desarrolladores que son dueños del servicio son dueños de sus tests unitarios, de contrato e integración — esos viven en el mismo repositorio y se lanzan en el mismo pull request que la funcionalidad. Quien sea dueño del proceso de release colabora en los tests end-to-end y de carga, porque esos necesitan entornos compartidos y datos realistas. Y las señales de producción — SLOs, umbrales de canary, ruteo de alertas — son trabajo de todos, porque son la única capa que sigue vigilando después de que el sprint terminó.

Los datos de prueba merecen su propia mención: los tests unitarios construyen datos en memoria por test; los de integración siembran una instancia fresca de Testcontainers por corrida, así que no hay una base de datos de fixtures compartida y decayendo que mantener sincronizada; los tests end-to-end y de carga necesitan un dataset mantenido, con forma de producción, en staging, que suele ser la parte de mayor mantenimiento y más descuidada de toda la estrategia. Presupuesta tiempo real para eso, porque un dataset de staging desactualizado convierte silenciosamente "corrimos la suite de e2e" en puro teatro.

#La forma, no solo la lista

Dibujado como una pirámide, esto es: muchos tests unitarios y de contrato en la base, una capa de integración significativa pero más pequeña, una capa delgada de tests end-to-end, y testing de carga más testing en producción como una banda continua en la parte de arriba en lugar de un gate de una sola vez — porque, a diferencia de cada capa de abajo, la observabilidad de producción nunca deja de correr.

#Cierre

Si trabajaste este curso desde la primera lección hasta esta, ya cubriste el mismo terreno que a los ingenieros senior les toma años acumular en el trabajo: cómo se mueve de verdad una petición a través de un sistema, dónde se rompe, cómo razonar sobre consistencia y falla, y — en este último módulo — cómo construir la confianza que le permite a un equipo lanzar sin contener la respiración. La estrategia de testing es un buen lugar para cerrar, porque es la disciplina que ata de vuelta a todos los demás temas de este curso: el diseño de una API solo importa si se prueba en la frontera correcta, la elección de una base de datos solo rinde frutos si su comportamiento de consulta se verifica contra el motor real, la resiliencia de un sistema distribuido solo es real una vez que se demostró bajo una falla que tú inyectaste a propósito, en lugar de una que te encuentra a las tres de la madrugada. Llévate el hábito más que cualquier respuesta puntual: sea cual sea el sistema sobre el que te pregunten la próxima vez, en una entrevista o en un post-mortem, hazte la misma pregunta que este curso repitió todo el tiempo — qué atraparía esto de verdad, qué tan barato, y qué tan pronto. Mucha suerte allá afuera.

🧠 Check your understanding
0/2 · 0/2 answered
1. En una estrategia de testing sana para un microservicio nuevo, ¿por qué importan los tests de contrato aunque los de integración ya ejerciten dependencias reales?
Los tests de contrato solo sirven para APIs públicas y externasLos tests de contrato verifican la forma exacta de petición/respuesta acordada con los servicios de otros equipos sin necesitar que esos servicios estén corriendo, atrapando cambios de API que rompen antes de que exista un entorno compartidoLos tests de integración ya cubren por completo la compatibilidad entre serviciosLos tests de contrato son más rápidos que los unitarios, así que los reemplazan
2. ¿Por qué el 'testing en producción' (análisis de canary, monitoreo sintético, alertas de SLO) pertenece a la estrategia incluso después de que ya pasaron los tests end-to-end y de carga?
Solo importa para servicios que no tienen entorno de stagingEs redundante y básicamente existe por razones de cumplimientoReemplaza por completo la necesidad de tests unitarios e integraciónLos entornos de preproducción no pueden reproducir del todo patrones de tráfico reales, datos reales y escala real, así que el monitoreo de producción es la única capa que sigue vigilando después de que todas las capas anteriores ya pasaron