Hola mi amigo y amiga de la calidad y colegas del mundo del desarrollo.

Si llevas algunos años en tecnología, probablemente aprendiste testing con esta clasificación: unit tests, integration tests y system tests. Es casi dogma. Lo repetimos en entrevistas, en cursos, en certificaciones. He conocido muchos desarrolladores que estas palabras les producen migraña. Y sabias que probablemente tengas eso en común con los desarrolladores de Google. ¿No me crees? Pues en este blog te voy a decir por qué

hace mucho que Google no organiza sus pruebas así. Y esto no me lo estoy sacando de la IA, sino del libro “How Google Tests Software”, que es el libro que estoy leyendo en este momento, te explico, que segun él ahora Google habla de Small, Medium y Large test, y esto no es sólo un cambio semántico, es un cambio en la forma de probar y automatizar.

El problema con “Unit, Integration y System”

Comencemos hablando que, segun ellos, el problema de esas etiquetas es que describen qué estás probando, pero no describen cómo se ejecuta esa prueba ni cuánto cuesta mantenerla.

En teoría:

• Unit test → prueba una unidad.
• Integration test → prueba integración.
• System test → prueba el sistema completo.

Pero en la práctica, esas categorías se vuelven ambiguas. Por ejemplo he visto “unit tests” que levantan bases de datos. mientras que hay “integration tests” que se pueden confundir con end-to-end. Y lo peor es que he trabajado en equipos con suites completas que nadie sabe exactamente qué son.

Si las categorías son difusas, la infraestructura también lo será. Google resolvió esto de forma distinta, y ya vamos a entrar en esa explicación.

Small, Medium, Large: una clasificación basada en ejecución

La clasificación no se basa en intención sino se basa en alcance, dependencias y tiempo de ejecución. Veamolos a detalle:

Small Tests

Son pruebas que verifican una unidad aislada de código. No tienen dependencias externas. No tocan red, base de datos real, todo se mockea o fakea. Con estos cambios las pruebas corren rápido, se ejecutan frecuentemente, y dan feedback inmediato.

Su objetivo es mantener el build “verde” y detectar problemas lo más temprano posible, y la parte mas interesante para mi es que: Google espera que la mayoría de las pruebas sean Small.

Medium Tests

Validan la interacción entre múltiples módulos. estas pruebas pueden usar recursos reales como bases de datos en memoria, pueden involucrar más de un componente, pero siguen siendo controladas. No deberían depender de infraestructura externa inestable y tienen límites claros de tiempo de ejecución.

Para entenderlo más fácilmente, esto sería un equivalente a “integration tests”.

Large Tests

Aquí hablamos de sistema completo que incluye:

• Interfaz de usuario.
• Red real.
• Infraestructura real.
• End-to-end.

Estas pruebas siempre serán necesarias, pero son más lentas, más costosas y más frágiles. Y por eso no deberían ser la mayoría. Y acá quiero hacer un insiso, porque la mayoria de las empresas con problemas de calidad y despliegue, insisten en hacer de estas pruebas, la mayoria y con las que esperan cubrir más en el sistema, y esto sin importar el nombre que elijas para la prueba, sigue siendo un error y Google lo confirma en este libro.

¿Por qué este cambio importa?

Porque Google no solo cambió nombres, sino que construyó infraestructura alrededor de estos tamaños, y como resultado su sistema de ejecución sabe cuánto puede tardar cada tipo, puede planificar recursos, cancelar pruebas que excedan límites y priorizar small tests para feedback rápido.

Digamos que es una clasificación operativa, que ayuda a un mejor proceso de despliegue y entrega de software.

La verdadera lección

Cuando estaba escribiendo Shift Left Testing en Pocas Páginas, entendí que no se trata de cuántas pruebas tienes. Se trata de dónde están y cuánto tardan en decirte que algo está mal.

Por ejemplo si tus pruebas más importantes tardan 40 minutos en ejecutarse, tu feedback es lento, o si la mayoría de tus pruebas son end-to-end, tu suite será frágil, también si tus small tests son pocos o inexistentes, cada error costará más.

Google no está obsesionado con pirámides dibujadas en un gráfico, sino esta enfocado en la velocidad del feedback y estabilidad del build. Con esto aumentan la calidad de sus productosde software.

El error que cometemos muchas empresas

Como te dije en algunos parrafos pasados, algunas empresas en la que he trabajado ponen mucho esfuerzo en construir suites enormes de pruebas end-to-end, para tener esa sensación de seguridad que genera que “todo esté automatizado”.

Pero cada cambio rompe diez pruebas, el pipeline se ejecuta lento o prescinde de estas pruebas. El equipo no confia en los resultados, y hasta a veces ni entiende que se esta probando realmente.

Entonces alguien dice: “Necesitamos más testers, hay que automatizar más, etc, etc etc”. Pero como te he dicho anteriormente problema no es la cantidad, sino en como se están distribuyendo las pruebas.

Calidad como estrategia de distribución

Un rápido resumen para terminar, recuerda esto

Small tests:

• Muchos.
• Rápidos.
• Deterministas.

Medium tests:

• Los suficientes.
• Enfocados.
• Con límites claros.

Large tests:

• Los estrictamente necesarios.

Mas allá de la teoria, recuerda que el propósito es siempre poder proveer un feedback más rapido y efectivo para el equipo.

📥 Recurso descargable: Plantilla práctica “Mapa de Distribución de Tests”

Para ayudarte a aplicar esto en tu equipo, aquí te dejo un recurso que puedes ofrecer como descargable:

Checklist: ¿Cómo está distribuida tu estrategia de pruebas?

Para cada suite o test:

Si te ha gustado este articulo, dejame saber en los comanterios para seguir creando articulos sobre este tema y este maravilloso libro que me esta ayudando a crear mucho contenido para ustedes. Nos vemos el próximo lunes.