Conviene automatizar una prueba cuando comprueba algo importante, puede repetirse de forma estable y su mantenimiento cuesta menos que el trabajo que evita. La primera decisión es qué comportamiento proteger, no qué herramienta instalar.
Elige por riesgo y repetición
| Caso | Prioridad orientativa |
|---|---|
| Cálculo usado en cada operación | Alta si sus reglas están definidas. |
| Integración que ya ha fallado | Revisar contrato y escenarios de error. |
| Pantalla que cambiará esta semana | Esperar a estabilizar o comprobar otra capa. |
| Valoración estética | Conservar revisión humana contextual. |
Una prueba automatizada compara un resultado con una expectativa. La documentación de pytest muestra cómo expresar y reportar esas comprobaciones mediante aserciones. Tener una herramienta no define por sí mismo qué expectativa es correcta para el negocio. Aserciones en pytest.
Empieza con una regla pequeña
Ejemplo hipotético: un descuento cambia según la cantidad comprada. Antes de automatizar todo el proceso de venta, documenta qué ocurre justo antes, en el límite y después del cambio de tarifa. El responsable comercial debe validar los resultados esperados.
Registra también entradas inválidas. Una prueba que sólo cubre el caso más cómodo puede seguir pasando mientras una excepción cotidiana falla.
Evita una colección de alarmas poco confiables
Si una prueba falla unas veces y otras no, investiga su dependencia de tiempo, datos compartidos o servicios externos. Reejecutarla hasta que pase oculta la incertidumbre y acostumbra al equipo a ignorarla.
Asigna mantenimiento a cada conjunto de pruebas. Cuando cambie una regla, revisa tanto la implementación como el resultado esperado; modificar la prueba sólo para obtener verde no valida el cambio.
La primera entrega útil puede ser un grupo pequeño que proteja una regla importante y se ejecute de forma repetible. Después decide dónde ampliar según los fallos que realmente podría detectar.
Compara tres candidatas concretas
| Candidata hipotética | Valor de automatizar | Condición para empezar |
|---|---|---|
| Regla de tarifa por cantidad | Detectar cambios involuntarios en límites repetidos. | Resultados esperados confirmados por el responsable. |
| Envío a otro sistema | Detectar rechazo o duplicado de una operación importante. | Contrato y entorno de prueba disponibles. |
| Diseño de una portada en revisión | Comprobar sólo comportamiento estable que importe. | No congelar decisiones visuales todavía abiertas. |
Para cada candidata, escribe qué error detectarías y cuánto trabajo requiere mantener la prueba. Si no puedes responder la primera pregunta, quizá estás comprobando cómo está escrito el código y no una necesidad. Empieza con una prueba que falle ante un error relevante conocido y pase cuando el comportamiento sea correcto.
Para profundizar en las tareas relacionadas: Qué comprueban las pruebas unitarias; Cómo comprobar una integración entre sistemas.
¿Hay un proceso que necesitas mejorar?
Cuéntanos qué ocurre hoy y qué resultado buscas. Podemos revisar una primera etapa para desarrollar o integrar la solución.
Explorar desarrollo de software
