Nombrar pruebas en Python con un formato consistente es tan importante como escribirlas. Si trabajas en equipo o mantienes proyectos open source, una convención clara para nombrar tests te ayuda a entender qué hace tu código sin leer cada línea, y facilita el soporte a largo plazo.

Esto va dirigido a desarrolladores que ya escriben pruebas unitarias y quieren mejorar la legibilidad de su suite de tests siguiendo prácticas reales de la comunidad.

¿Por qué PEP 8 no basta para nombrar pruebas?

PEP 8 define el estilo general del código en Python: indentación, espacios, longitud de línea, convenciones de nombres para variables y funciones. Pero no dice nada sobre cómo nombrar tus pruebas.

Esto deja un vacío que cada equipo debe llenar. Y aquí viene lo interesante: si no defines una convención propia, terminarás con nombres como test_1, test_deposit_ok o test_funciona, que no le dicen nada a quien revise el proyecto después.

¿Qué cubre PEP 8 en Python? Define el estilo de código: nombres de variables, funciones, clases, espaciado e indentación. No incluye reglas para nombrar pruebas unitarias.

Por eso, como desarrollador, te toca definir esa guía dentro de tu proyecto. Y conviene apoyarte en formatos que ya usan otros equipos.

¿Cómo organizar los tests en clases mapeadas al proyecto?

Antes de pensar en el nombre de cada prueba, agrupa los tests en clases. La regla es simple: cada clase de tu proyecto tiene su clase espejo de pruebas [00:38].

Por ejemplo, si tienes una clase BankAccount, su contraparte de pruebas se llama BankAccountTest. Esa relación uno a uno hace que cualquier persona del equipo encuentre rápido dónde están las pruebas de cada componente.

Dentro de esa clase agrupas todos los tests que validan el comportamiento de BankAccount, sin mezclar lógica de otros módulos.

¿Cuál es el formato recomendado para nombrar cada prueba?

El formato favorito que te propongo, muy usado en proyectos open source, se construye con cuatro piezas en orden [01:00]. Cada una aporta contexto.

• Prefijo test_: obligatorio para que el test runner lo reconozca como prueba.
• Método bajo prueba: el nombre del método que estás validando, por ejemplo deposit.
• Escenario: la condición o valor de entrada que estás probando, como positive_amount.
• Resultado esperado: una frase corta que describa qué debería pasar, como increase_balance.

Uniendo las piezas, el nombre completo queda así: test_deposit_positive_amount_increase_balance. Con solo leerlo sabes qué método se prueba, bajo qué condición y qué se espera que ocurra.

¿Cómo defines el escenario de una prueba?

El escenario sale de mirar la firma del método. Vas a la clase, ubicas el método y revisas sus parámetros [01:30]. Para deposit(amount), el parámetro amount puede recibir un valor negativo, cero o positivo.

Cada uno de esos valores es un escenario distinto. Si decides probar el caso positivo, tu escenario se llama positive_amount. Si más adelante pruebas el negativo, tendrás otro test con negative_amount en el nombre.

¿Qué partes lleva un nombre de test bien formado? Lleva cuatro: el prefijo test_, el método probado, el escenario de entrada y el resultado esperado. Ejemplo: test_deposit_positive_amount_increase_balance.

¿Cómo describes el resultado esperado?

Después del escenario, agregas una frase corta que responda: ¿qué va a pasar? En el caso de un depósito con valor positivo, el saldo de la cuenta debería incrementarse, así que usas increase_balance [02:00].

La idea es que el nombre cuente una historia mínima: método, entrada, salida. Sin necesidad de abrir el cuerpo de la prueba.

¿Qué beneficios tiene nombrar pruebas con un formato claro?

Leer solo el nombre del test te dice qué está haciendo tu aplicación. Eso ahorra tiempo en revisiones de código, onboarding de nuevos miembros del equipo y soporte de pruebas viejas.

• Tu equipo entiende la intención sin leer la implementación.
• El soporte de pruebas se vuelve más rápido cuando algo falla.
• La suite de tests funciona como documentación viva del comportamiento del código.

Esto no es obligatorio. PEP 8 no lo exige y Python tampoco. Pero es una práctica que escala bien y se nota en proyectos grandes.

¿Cómo aplicar este formato a tu proyecto actual?

El reto es directo: revisa las pruebas que ya escribiste y refactoriza sus nombres usando la estructura de cuatro piezas [02:30]. Imagina escenarios nuevos que aún no estás cubriendo, como valores negativos o cero en deposit.

Después compara tu refactor con la versión que se sube en la sección de recursos del curso. Vas a notar diferencias y similitudes, y ahí está el aprendizaje.

Cuéntame en los comentarios qué nombres tenías antes y cómo quedaron después de aplicar el formato.