Respuesta.

Al trabajar con pruebas automatizadas, una estructura adecuada es clave para su eficacia y viabilidad.

Historia del tema

Anteriormente, las pruebas automáticas a menudo se creaban como scripts monolíticos y estrechamente vinculados. Esto complicaba su mantenimiento y expansión. El aumento en el número de pruebas destacó la importancia de una arquitectura adecuada.

Problema

Sin una estructura clara, surgen:

duplicación de código
dificultades para mantener con cambios en los requisitos
baja legibilidad y alta probabilidad de errores

Solución

Utiliza niveles claros de abstracción para tus pruebas:

Escenarios de prueba deben invocar pasos y métodos de negocio ya implementados, y no detalles de implementación.
Nivel de negocio encapsula acciones del usuario (por ejemplo, "crear pedido"), sin revelar detalles técnicos.
Nivel técnico (por ejemplo, Page Object) trabaja con elementos UI o API.

Una buena práctica es usar:

# Ejemplo de estructura
/tests
  /features
    test_order_creation.py
  /steps
    order_steps.py
  /pages
    order_page.py

Características clave:

Clara separación de responsabilidades (por capas, módulos)
Máxima reutilización de código
Facilidad de realizar cambios (solo es necesario cambiar una entidad)

Preguntas trampa.

¿Qué es mejor: escribir pruebas end-to-end largas o pruebas automáticas modulares cortas?

A menudo se eligen solo las end-to-end, pero es importante combinar diferentes tipos de pruebas según los objetivos: todos los niveles (Unit, API, UI) son importantes para una verificación de calidad.

¿Se pueden usar en las pruebas comprobaciones de UI por texto y localizadores al mismo tiempo?

No siempre es correcto: se pueden usar ambos métodos simultáneamente, pero solo si la variabilidad del UI y la lógica de la prueba lo justifican. A menudo es redundante y complica el mantenimiento.

¿Debería copiarse completamente la estructura del sistema del software a probar al crear pruebas automáticas?

No, la estructura de las pruebas automáticas debe estar orientada a facilitar las pruebas, no a replicar exactamente la arquitectura de la aplicación.

Errores comunes y anti-patrones

Hardcodeo de datos de prueba directamente en las pruebas
Copia de las mismas acciones en cada prueba
Scripts "todo en uno": prueba que ejecuta muchos escenarios a la vez

Ejemplo de la vida real

Caso negativo

En un equipo, las pruebas automáticas eran escritas por una persona, las pruebas estaban en un solo archivo, cada prueba copiaba los pasos de la anterior. Al actualizar la interfaz, el error se corregía manualmente en todas las pruebas.

Pros:

Escritura rápida de pruebas básicas

Contras:

Cambios en la lógica de negocio requerían una reescritura obligatoria de todas las pruebas, a menudo con errores

Caso positivo

En otro equipo se implementó un patrón arquitectónico (separación de pasos, páginas, pruebas). Los nuevos empleados se adaptaban rápidamente e implementaban nuevas pruebas con rapidez, las actualizaciones se realizaban en un solo lugar.