Get best of the week

4 mejores patrones de diseño para pruebas automatizadas (y 86 más)

Hola a todos. En previsión del comienzo del curso, "Python QA Engineer" preparó una traducción de otro material interesante.



La mayor parte del éxito de sus proyectos de automatización radica en la reutilización de patrones de prueba conocidos, que, como ya se ha demostrado, ayudan a aumentar la fiabilidad de los escenarios de automatización.

Un patrón de diseño de prueba automatizado es una solución simple que demuestra su eficacia para el mundo día a día. Estas plantillas también se consideran las mejores prácticas para cualquier proyecto creado con programación orientada a objetos.

¿Por qué los patrones de diseño son tan importantes para las pruebas automatizadas?

Dé por sentado que sus aplicaciones cambiarán con el tiempo.
Y como sabe que el cambio ocurrirá de una forma u otra, debe usar las mejores prácticas y patrones de diseño desde el principio. Harán que sus pruebas sean reutilizables y más fáciles de mantener.

Aquí hay algunos patrones comunes de diseño de pruebas automatizadas que muchos equipos usan para crear una automatización de pruebas robusta y mejorar toda la lógica de prueba.

Objetos de página



Un ejemplo de Objeto de página por Nikolay Advolodkin de Automation Guild 2017

Una de las estrategias populares utilizadas en la automatización de pruebas es modelar el comportamiento de su aplicación.
Para hacer esto, puede usar objetos de página simples que simulan las piezas de software que está probando.
Por ejemplo, puede escribir un objeto de página para una página de inicio de sesión o página de inicio. Este enfoque refleja correctamente el principio de responsabilidad compartida.

Si algo cambia, digamos, la ID del elemento, entonces necesitará cambiar solo un lugar en el código, y todas las pruebas que usen este objeto de página recibirán automáticamente este cambio sin acciones innecesarias. El código de prueba solo debe actualizarse en un lugar. Este enfoque también ayuda a reducir la duplicación de código.

Los objetos de página también ocultan los detalles técnicos de HTML y CSS detrás de los métodos con nombres simples y claros.
La atención a la denominación de sus métodos tiene la ventaja adicional de ayudar a crear una interfaz de programación de aplicaciones (API) agradable y legible que un programador con menos conocimientos técnicos puede comenzar a usar rápidamente.

Este patrón también sigue la práctica popular de desarrollo de software DRY (No te repitas, no lo repitas).
Básicamente, el principio DRY significa que para cada parte de la lógica, una sola pieza de código y ninguna más deberían ser responsables. La duplicación en el código dificulta el mantenimiento; cuanto menos código escriba, mejor, ya que un código más compatible significa más posibilidades de que un error se infiltre en su marco de prueba.

Esta plantilla de diseño de software por sí sola puede resolver fácilmente la mayor parte de sus problemas de prueba, pero tampoco es una panacea. Sin embargo, le permitirá dar un gran paso adelante, haciendo que sus pruebas funcionales automatizadas sean más estables.
Algunos evaluadores argumentan que el patrón de Objeto de página a menudo viola el principio de que una clase debería tener solo una razón para cambiar.

Para evitar esto, muchos recurren al guión, que fue descrito por primera vez por Anthony Marcano ( @AntonyMarcano) con la participación de Andy Palmer ( @AndyPalmer), Jan Molak ( @JanMolak) y otros.

Patrón de guion


Los objetos de página son una buena manera de comenzar a hacer que sus pruebas sean mantenibles, pero si no tiene cuidado, aún pueden salirse de control con el tiempo.
El patrón Screenplay (una vez conocido como patrón Journey) es una aplicación de principios de diseño SOLID para pruebas de aceptación automatizadas y ayuda a los equipos a resolver estos problemas. De hecho, esto es lo que fue el resultado de una refactorización despiadada de los objetos de página utilizando los principios de diseño SOLID.

El patrón Screenplay toma objetos de página y los divide en pedazos realmente pequeños. Algunos probadores dicen que esto ha hecho que sus pruebas sean más fáciles de mantener y confiables.
Otra ventaja importante es que hace que los scripts de prueba sean más legibles.

La primera vez que escuché sobre el patrón Screenplay en la Automation Guild Session en 2017 fue de John Smart (el @Wakeleo)creador de uno de mis marcos de automatización de pruebas favoritos, Serenity .
Screenplay utiliza la idea de actores, tareas y objetivos para describir formalmente las pruebas, rechazando los términos de interacción con el sistema. Guión, usted describe las pruebas en términos de un actor que tiene objetivos.

Aquí hay un ejemplo:


un ejemplo de la implementación del patrón Guión de la Automation Guild Session 2017 por John Smart

A primera vista, puede parecer que usar este patrón es mucho más difícil que los mismos Objetos de página, pero John mencionó que usar este enfoque ahorra mucho tiempo a los equipos con los que trabajó al reducir el costo de mantenimiento y soporte.

Puertos y Adaptadores


La arquitectura de los puertos y adaptadores tiene como objetivo garantizar que utilice el principio de responsabilidad única , es decir, un objeto específico debe hacer una cosa y tener una sola razón para el cambio.
Cuando lo use en automatización, asegúrese de separar el código del caso de prueba de todo lo demás para poder intercambiar componentes lentos y simuladores rápidos, lo que le permite ejecutar la prueba y la aplicación bajo prueba en un solo proceso.

Deshágase de las redes y E / S para que nada ralentice el conjunto de pruebas. Por supuesto, esto no es fácil de hacer, pero cuanto más se esfuerce por crear la automatización de la interfaz de usuario, mejor será para usted.

Aprendí sobre este patrón durante una entrevista con el creador de Cucumber , Aslak Hellesoy ( @aslak_hellesoy)lo describió como una estrategia para obtener comentarios rápidos de las pruebas de extremo a extremo de Cucumber.

Aslak también recomendó un recurso llamado Todo-subsecond , que agregué a mi publicación Top Resource para Ingenieros de automatización de pruebas : esta pequeña aplicación con pruebas de aceptación de pila completa que se puede completar en milisegundos está diseñada para ilustrar los métodos básicos para lograr esto en cualquier sistema. Después de completar una serie de ejercicios, aprenderá una forma especial de implementar desarrollo impulsado por el comportamiento.

Presentador primero


Presenter First es una modificación del modelo-vista-controlador (MVC) para organizar el código y el desarrollo a fin de crear un software completamente probado utilizando un enfoque de desarrollo basado en pruebas (TDD).
Conocí este patrón por primera vez en una entrevista con Sab Rose (@SebRose), uno de los contribuyentes al proyecto Cucumber y autor de Cucumber for Java.
Dijo que si dibuja el patrón MVC en forma de bloques y flechas, verá que la vista, que es su interfaz de usuario, tiene conexiones claramente definidas con el modelo y el controlador. Si en tiempo de ejecución puede reemplazarlos por modelos y controladores que su prueba crea y controla, entonces no habrá ninguna razón por la cual no pueda verificar que la interfaz de usuario no se comporte de la manera deseada.

También puede personalizar su modelo y controlador para que simulen todo tipo de comportamientos extraños, por ejemplo, fallas de la red.

86 otros patrones de prueba automatizados


Escribí este artículo hace muchos meses, pero nunca lo publiqué.
Tenía confianza en mi lista hasta que hablé con Seretta Gamba , autora del nuevo libro Un viaje a través de patrones de automatización de pruebas , donde ella y su coautora Dorothy Graham hablan sobre 86 patrones.

Desglosan los patrones en cuatro categorías distintas: patrones de proceso, patrones de control, patrones de diseño y patrones de ejecución.
Los que describí se refieren a patrones de diseño, pero hay muchos otros patrones que resuelven problemas no solo con el código.

Por ejemplo, hay patrones que se relacionan con la mala cultura corporativa y los modelos de gobierno que, en mi experiencia, tienden a anular todos los esfuerzos para automatizar las pruebas.
Para obtener una lista completa, consulte el wiki de patrones de diseño o solicite un libro de Amazon.

Aprende más sobre el curso.

More articles:


All Articles