El naming de los test
23-09-2025
Desde mi primera línea de código siempre me he preguntado sobre mejores formas de nombrar los tests. El naming está muy relacionado con el diseño de software, plasmando el conocimiento en código. En este artículo veremos ejemplos que ilustran tópicos importantes a la hora de intentar darle forma a nuestros tests.
Pero primero me gustaría recordar que nuestros tests son la documentación viva del comportamiento del sistema, por lo que cuidarlos nos ayudará a mantener un software sano. Sin embargo, esta es un arma de doble filo, porque no siempre es el caso de que ayuden; muchas veces ralentizan más que el propio código de producción. Podemos ilustrarlo con el siguiente ejemplo:
class TestCalculation: def test_calculate(): // code goes here...
Es curioso que un código genere más preguntas que respuestas. Me surge la pregunta: ¿qué calcula? Si falla, ¿qué ha fallado en el cálculo? Con esto quiero ilustrar que si vemos en nuestra batería de tests:
❌ TestCalculation::test_calculate
Estamos forzados a cargar cognitivamente el contenido de este test, que muy probablemente englobe muchos conceptos para ahorrar algo de tiempo en el desarrollo. Otra desventaja es que cuando pasen unos días, empezarás a olvidar lo que calculaba. Entonces surge la necesidad de hacerlo mejor y obtenemos:
class TestInvoiceCalculation: def test_given_four_products_when_calculate_the_total_then_substract_the_discount_and_apply_taxes(): // code goes here...
Este es un ejemplo de convención de test compuesto de argumentos, función bajo el test y los comportamientos esperados. Estas convenciones muchas veces se caen por su propio peso porque si cambiamos el método calculate habrá que cambiar todos los nombres de los tests que hagan referencia.
💡 En el libro The Memory Illusion se comenta que solo somos capaces de manejar de 4 a 7 piezas de información, por lo que si no vamos al grano en el nombre, se nos empezarán a olvidar piezas.
Si se te hace difícil nombrar el test recuerda que siempre se pueden cambiar luego, por ejemplo es muy común que en los tests funcionales no dejarse detalle fuera. A mí me ayuda quitar detalles como given_four_products no me dice nada en el nombre, ya que si miro el test soy capaz de verlo. Podemos inferir la regla de negocio de que si hay varios productos puede haber un descuento y empezar a enriquecer al test quitando todo aquello irrelevante.
class TestInvoiceCalculation: def test_calculate_the_total_then_substract_the_discount_and_apply_taxes(): // code goes here...
Por otro lado, parece que es demasiado largo, fijémonos en el and parece que al intentar nombrar nos damos cuenta de que miramos dos cosas diferentes en el mismo test substract_the_discount y apply_taxes. La solución es simple, con duplicar código y mirar dos cosas diferentes solucionamos el problema.
class TestInvoiceCalculation: def test_calculate_the_total_then_apply_taxes(): // code goes here... def test_calculate_the_total_then_substract_the_discount(): // code goes here...
Vamos a ir solucionando problemas poco a poco, por ejemplo, el nombre de la clase, podemos jugar con ella tanto para dar contexto como legibilidad, la idea es que sea fácil de leer como un libro junto con sus métodos que son las acciones del sistema sin entrar al detalle:
class InvoiceCalculationWhenCalculatesTheTotalShould: def test__apply_taxes(): // code goes here... def test__substract_the_discount(): // code goes here...
Los tests se leerían desde la terminal como:
❌ InvoiceCalculationWhenCalculatesTheTotalShould::test__apply_taxes ❌ InvoiceCalculationWhenCalculatesTheTotalShould::test__substract_the_discount
He elegido Python porque hay una limitación con los nombres que te obliga a poner test_ como un prefijo de cada método de test. Como represalia, he puesto dos guiones bajos para separar mi regla del sistema de la limitación tecnológica.
Si se fijan detenidamente, he buscado la opción que más legibilidad me aporta. Por ejemplo, en JavaScript la frase es mucho más fácil de construir gracias a la influencia de Rspec:
describe("Footer should ", () => { describe("on both window sizes", () => { it("copy the email to clipboard", () => { //...
No te conformes con dejar pasar nombres malos; estos te perseguirán y te darán más ganas de borrarlos que de mantenerlos. Piensa que el código de los tests vale tanto como el de producción. Acuerda primero algunas reglas con tu equipo y a disfrutar del proceso. Me despido dejando algunos recursos.
