Respuesta.

Historia de la pregunta:

Inicialmente, las pruebas automáticas a menudo se escribían "a la brava", sin separaciones arquitectónicas: la lógica de verificación y los mecanismos de ejecución se mezclaban. Con el crecimiento de los proyectos, se volvió evidente que la mezcla del marco y la lógica de prueba crea una base de código frágil y difícil de mantener. Surgieron recomendaciones arquitectónicas para la separación de responsabilidades.

Problema:

Si las pruebas dependen de implementaciones internas del marco o incluyen lógica de interacción con el entorno, cualquier cambio obliga a reescribir numerosas pruebas. Los casos de prueba son complejos, el código se duplica, la migración a un nuevo marco o plataforma es problemática.

Solución:

Separar estrictamente:

Marco (infraestructura base): la mecánica general para ejecutar pruebas, registro, manejo de errores, informes, base para clases auxiliares (por ejemplo, controladores, adaptadores y utilidades).
Lógica de prueba (casos de prueba): escenarios específicos que expresan el objetivo semántico de la prueba, utilizando solo las API públicas del marco.

Características clave:

Facilidad de mantenimiento gracias a la isolación de cambios de plataforma
Posibilidad de reutilizar la lógica de prueba
Reducción de redundancia y duplicación de código

Preguntas trampa.

¿Se pueden escribir pasos de prueba directamente en las pruebas si son muy pocas?

No se debe. Incluso las pruebas cortas pueden crecer, y la falta de capas rápidamente conducirá al caos.

¿Deben los escenarios de prueba conocer la mecánica de ejecución (por ejemplo, cuándo inicializar el controlador)?

No. Todos los detalles de infraestructura deben ocultarse en la capa del marco.

¿Es normal codificar parámetros de prueba dentro de los casos (por ejemplo, url, credenciales)?

No. Los parámetros de prueba deben configurarse a través de la configuración del marco y del entorno.

Errores comunes y anti-patrones

Colocar verificaciones de estado dentro de los métodos del marco, en lugar de en las pruebas
Uso de métodos privados del marco en las pruebas
Duplicación de funciones auxiliares en las pruebas
Codificación de parámetros

Ejemplo de la vida real

Caso negativo

En el proyecto, las pruebas llaman directamente a los métodos del controlador Selenium, en cada prueba se repite la conexión a WebDriver. Cada prueba analiza por sí misma la configuración.

Ventajas:

Se puede empezar a escribir pruebas automáticas rápidamente sin arquitectura

Desventajas:

Cambiar el controlador o los parámetros de ejecución lleva a modificaciones masivas
Código duplicado en todas las pruebas
Difícil de escalar y mantener el proyecto

Caso positivo

Las pruebas utilizan abstracciones básicas del marco: inicialización y teardown generales, transmisión continua de parámetros a través de un configurador, la lógica de prueba se expresa a través de métodos de alto nivel.