Qué comprueban las pruebas unitarias

Una prueba unitaria comprueba una parte pequeña del software en condiciones controladas. Sirve para detectar si una regla cambia de forma inesperada; no demuestra por sí sola que todo el sistema funcione.

Un ejemplo de regla

Supón una función que aplica una tarifa según cantidad. Antes de probarla, el negocio debe definir qué importe corresponde a cada caso, incluido el límite donde cambia la tarifa. Si la regla está ambigua, automatizarla sólo fijará una interpretación.

Cómo se expresa el resultado

La prueba ejecuta una operación y contrasta su salida con una expectativa. Herramientas como pytest ofrecen aserciones y mensajes de fallo para hacer visible esa diferencia. Cómo escribir aserciones.

Ejercicio pequeño con resultados explícitos

Regla ficticia para practicar: de 1 a 9 unidades se devuelve 100; desde 10, se devuelve 90. Son valores didácticos, no precios ni tarifas de Acinsoft.

def tarifa(cantidad):
    if type(cantidad) is not int or cantidad < 1:
        raise ValueError("La cantidad debe ser un entero positivo")
    return 90 if cantidad >= 10 else 100

assert tarifa(9) == 100
assert tarifa(10) == 90
assert tarifa(11) == 90
try:
    tarifa(0)
except ValueError:
    pass
else:
    raise AssertionError("Debía rechazar cero")

Los casos 9, 10 y 11 comprueban la frontera de la regla; el caso cero comprueba un rechazo. Si se cambia por error >= por >, el caso de 10 debería detectarlo. Para un proyecto real, amplía sólo los casos relevantes y valida la regla con su responsable. Estas pruebas no envían formularios ni guardan importes en una base de datos.

Qué queda fuera

Que el cálculo pase no acredita que el formulario envíe la cantidad correcta o que la base de datos guarde el importe. Esas conexiones requieren otras comprobaciones. Por eso conviene distinguir pruebas unitarias, de integración y del recorrido completo del usuario.

Tampoco es útil exigir pruebas para cada detalle sin considerar valor y mantenimiento. Prioriza reglas importantes, condiciones límite y errores que sería costoso volver a introducir.

Al revisar una entrega, pide un ejemplo de la regla protegida y cómo se detectaría una regresión. Un porcentaje de cobertura aislado puede describir ejecución de código sin mostrar si se comprobaron resultados relevantes.

Para profundizar en las tareas relacionadas: Qué pruebas de software conviene automatizar primero; Cómo comprobar una integración entre sistemas.