Kent Beck: el poder de los «composable tests» en 2026

Kent Beck reescribe las reglas: qué son los "composable tests" y por qué deberían importarle a tu startup

Kent Beck no es un teórico cualquiera. Es el creador de Extreme Programming y codesarrollador, junto a Ward Cunningham, del Test-Driven Development (TDD). Cuando Beck publica una nueva idea sobre testing, la comunidad de ingeniería escucha: lleva escribiendo sobre cómo escribir software desde 1996, cuando tomó el liderazgo del proyecto Chrysler Comprehensive Compensation System (C3) y formalizó las prácticas que después se conocerían como XP, según recoge la entrada de Wikipedia sobre Extreme Programming. Casi treinta años después, sigue empujando los mismos principios hacia nuevos límites.

En su newsletter del 10 de noviembre de 2025, Beck presentó un giro aparentemente pequeño pero incómodo para muchos ingenieros: los tests no deberían estar aislados solo entre sí, también deberían poder componerse. La diferencia entre ambas ideas es el núcleo de un debate que afecta directamente a la velocidad de iteración de cualquier producto de software, y, por extensión, al ritmo de entrega de una startup.

Aislar y componer: dos propiedades que parecen iguales pero no lo son

Beck parte de los Test Desiderata, una lista de propiedades deseables en una suite de pruebas. Las dos que más confusión generan son Isolation y Composition.

Isolation es la idea clásica que promueven los frameworks xUnit: cada test crea su propio fixture desde cero, ejecuta su setUp() y corre de manera independiente del orden y de los resultados de los demás. Es el equivalente a la transparencia referencial de la programación funcional: el resultado de un test no depende de ningún otro.

Composition, en cambio, dice que varios tests deberían poder combinarse y que el resultado del conjunto siga dando confianza (sea predictive, en la terminología de Beck) aunque cada test por separado no sea exhaustivo. La trampa está en que composition no contradice isolation: un test puede ser aislado y aun así componerse con otros sin perder su valor.

El ejemplo que lo aclara todo

El propio Beck reconoce, con franqueza, que lo difícil siempre es encontrar un buen ejemplo. Y lo aporta.

Supongamos que tenemos un test inicial:

test1()
  object := new Whatever()
  actual := object.doSomething()
  assertEquals(expected, actual)

Cuando queremos añadir funcionalidad, copiamos, pegamos y extendemos:

test2()
  object := new Whatever()
  actual := object.doSomething()
  assertEquals(expected, actual)
  actual2 := object.nowSomethingElse()
  assertEquals(expected2, actual2)

Beck asegura haber visto tests copiados, pegados y extendidos 6 o 7 veces. El último se vuelve casi ilegible. Y aquí viene el punto clave: test2 no puede pasar si test1 falla, porque un programa que rompa doSomething() también romperá doSomethingElse(). La cobertura es la misma, pero la legibilidad se hunde.

Frente a eso, Beck plantea tres opciones que conservan cobertura y predictibilidad:

• Dejar los dos tests tal cual (redundantes).
• Borrar test1 (perdemos specificity: cuando un test falla, sabemos exactamente dónde está el problema).
• Simplificar test2 (su opción favorita), podando las aserciones redundantes con el test anterior:

test2()
  object := new Whatever()
  object.doSomething()
  actual := object.nowSomethingElse()
  assertEquals(expected, actual)

La composición de test1 + test2 no pierde predictive power ni specificity. De hecho, puede volverse más específica, porque teóricamente test1 puede fallar y test2 pasar.

La regla N x M: por qué esta idea cambia cómo escribimos suites grandes

Donde la composición brilla es en problemas combinatoriales. Si tenemos 4 formas de calcular intereses y 5 formas de reportarlos, la fuerza bruta exige 20 tests separados. Con composición, la misma confianza se consigue en 10. Y si las variantes de cálculo están separadas, en sentido funcional, de las variantes de reporte, basta con:

• 4 tests para el cómputo.
• 5 tests para el reporte.
• 1 test que combine ambos extremos para demostrar que están bien conectados.

Ganancias que Beck promete con la composición:

• Tests más rápidos.
• Tests más legibles.
• Tests más fáciles de cambiar.
• Tests más específicos al fallar.
• Tests menos sensibles a cambios de estructura.

El coste es real: hace falta invertir pensamiento, algo de inferencia y algo de diseño (para demostrar que las dimensiones son ortogonales). Pero el retorno, según Beck, lo compensa con creces.

La crítica que recibe: "yo nunca reduciría aserciones"

Beck reconoce que explicar esta idea suele provocar rechazo entre desarrolladores experimentados. La frase típica: "yo nunca reduciría las aserciones en un test". Su lectura es que la reacción viene más del miedo que del principio: costó tanto introducir testing en la cultura del software que cuesta aceptar hacerlo diferente.

La respuesta de Beck es directa: composición no empeora los tests. Composición mira los tests como un sistema completo y procura mejorar el todo de acuerdo con varias propiedades valiosas a la vez.

En los comentarios del post, el desarrollador italiano Matteo Vaccari apuntó un riesgo real: si doSomething() tiene un bug, el estado en el que se ejecuta doSomethingElse() es desconocido. El test puede fallar en nowSomethingElse() por algo que en realidad es un fallo aguas arriba. Vaccari propuso usar, en frameworks que lo soporten, aserciones tipo assumeTrue(object.isReadyToDoSomethingElse()) para distinguir fallos de suposiciones de fallos reales de la unidad bajo prueba.

Qué significa esto para tu startup

Más allá del debate teórico, la propuesta de Beck se traduce en decisiones prácticas que un fundador debe tomar sobre cómo su equipo escribe y mantiene tests. La velocidad de iteración de un SaaS joven depende casi tanto de la calidad de su suite de pruebas como del código de producción: cada minuto que un developer pasa interpretando un test ofuscado es un minuto que no se está sumando al producto.

Acción concreta 1: audita tu suite de tests y detecta la deuda de duplicación. Busca tests que sean versiones extendidas de otros anteriores con aserciones repetidas al inicio. Esa copia-pega acumulada es candidata natural a composición: elimina la aserción redundante y deja solo la nueva. En frameworks como JUnit, Jest o pytest, basta con reordenar y eliminar assert previos que ya estén cubiertos por otros tests.

Acción concreta 2: separa dimensiones ortogonales y comprueba combinaciones con un test único. Si tu producto tiene variaciones (por ejemplo, 3 métodos de cobro y 4 formatos de factura), escribe tests focalizados en cada dimensión por separado y un único test de integración que las combine. Reducirás tiempo de ejecución y harás que cada fallo apunte con más precisión al módulo responsable, que es justo la "specificity" que Beck reivindica.

Fuentes

• Composable Tests (fuente original)
• Extreme programming (contexto sobre Kent Beck y XP)