Hace poco m谩s de un a帽o, prob茅 por primera vez el Robot Framework. Durante mi participaci贸n en un proyecto a gran escala, experiment茅 dos enfoques diferentes para la automatizaci贸n de pruebas con esta herramienta: escribir pruebas en un marco de robot DSL puro y trabajar en conjunto con Python. Si el primer camino tiene un umbral de entrada bajo, entonces el segundo, en mi opini贸n, es m谩s conveniente desde el punto de vista de apoyar grandes proyectos. Aunque no hay una diferencia fundamental entre los enfoques. De una forma u otra, todo se reduce a encontrar bibliotecas.
Sin embargo, vale la pena hablar sobre las caracter铆sticas de los enfoques.
驴Qui茅n es Robot y con qu茅 come?
Probablemente valga la pena comenzar con la introducci贸n de esta poderosa herramienta.
Robot Framework es un marco para pruebas basadas en palabras clave. Se utiliza para automatizar las pruebas de aceptaci贸n y ATDD (enfoque de desarrollo a trav茅s de las pruebas de aceptaci贸n). Este sistema tiene una sintaxis de datos de prueba f谩cil de usar y le permite automatizar las pruebas usando palabras clave. Adem谩s, Robot Framework tiene excelentes bibliotecas integradas y de terceros que le permiten iniciar e integrar r谩pidamente la automatizaci贸n en los procesos de trabajo sin inventar sus propias bicicletas, el umbral de entrada muy bajo que mencion茅 anteriormente.
La estructura b谩sica de Robot Framework se implementa usando Python y tambi茅n funciona en Jython (JVM) y IronPython (.NET).
Se pueden encontrar ejemplos de uso, as铆 como documentaci贸n completa sobre el marco y las bibliotecas internas en el sitio web oficial del proyecto:
http://robotframework.org/ .
Mis primeros pasos Primer acercamiento
Por primera vez, me encontr茅 con el Robot Framework hace un a帽o, despu茅s de cambiar mi trabajo. Antes de eso, solo hab铆a automatizado en Java y C #.
Eligiendo por m铆 mismo las herramientas con las que tengo que lidiar con las pruebas existentes, entrevist茅 a nuevos colegas sobre sus preferencias. No acordaron el mejor IDE para trabajar con Robot Framework. Los complementos para varios editores de texto e IDE, como PyCharm, permiten trabajar principalmente con Robot Framework. Y las recomendaciones que recopil茅 se dividieron 50/50 entre Atom y PyCharm. Por supuesto, hay RIDE, pero esto no es una panacea. En ese momento (hace un a帽o), no encontr茅 la documentaci贸n normal en 茅l, y en el que encontr茅, no vi grandes ventajas para mi tarea. Por lo tanto, para empezar, decid铆 probar Atom con complementos. Al clonar el repositorio, comenc茅 a estudiar lentamente lo que estaba sucediendo en nuestras pruebas y en el propio Robot Framework.
Me he conectado al proyecto para pr谩cticamente todo. Un mont贸n de Jython + Robot Framework ya funcionaba all铆, se ensambl贸 una enorme base de c贸digo (escrita en el propio DSL Robot Framework) a partir de m谩s de 1000 pruebas y varios miles de l铆neas de c贸digo de bibliotecas auxiliares en Java.
Seg煤n tengo entendido, cuando comenz贸 el proyecto, es decir incluso antes de llegar al departamento, eran principalmente especialistas en Java quienes trabajaban en 茅l, y el producto que se estaba probando estaba en Java, por lo que al elegir un enfoque, nos centramos en los recursos disponibles. En general, el c谩lculo fue algo como esto: despu茅s de resolver algunos problemas relacionados con la integraci贸n de Robot Framework y Java (principalmente debido al hecho de que Java es un lenguaje compilado, pero se interpretan el mismo Python y las pruebas en el paquete Python + RF), luego Es f谩cil atraer a expertos de terceros que solo conocen el DSL Robot Framework y escribir pruebas silenciosamente sobre palabras clave. Es cierto que los colegas tuvieron que dedicar mucho esfuerzo a crear bibliotecas en Java, por lo tanto, sin condiciones del cliente, no recomendar铆an ese camino.
Despu茅s de refactorizar un poco, como parte de mi primera tarea, primero realic茅 las pruebas. Como se us贸 el paquete Jython + RF, todo fue recopilado por maven, y los archivos del robot simplemente se copiaron en el directorio de destino para su posterior ejecuci贸n.
Las pruebas se ejecutaron mediante scripts (archivos .bat o .sh) que tomaron la ruta a un caso de prueba separado (un archivo .robot separado) o un plan de prueba (un archivo con una lista de rutas relativas a los casos de prueba).
La refactorizaci贸n afect贸 una gran cantidad de pruebas, por lo que la primera ejecuci贸n tard贸 unos 15 minutos. Despu茅s de su finalizaci贸n, es hora de echar un vistazo a los informes proporcionados por Robot Framework.
El informe est谩ndar (en la captura de pantalla anterior) consta de los archivos report.html y log.html:
- el informe contiene un resumen general de la pasada ejecuci贸n, donde puede ver los resultados de la superficie de todas las pruebas (Aprobado o Fallido);
- en el archivo de registro puede ver informaci贸n m谩s detallada: la ejecuci贸n de cada prueba paso a paso. All铆 puede mostrar todo lo que necesita para depurar las pruebas.
Honestamente, desde el primer vistazo al informe de Robot Framework, el ojo comienza a temblar un poco: se muestra una gran cantidad de informaci贸n y toma algo de tiempo comprender la estructura de extremo a extremo de las pruebas y desarrollar la habilidad para leer dicho registro. Pero este negocio no es tan complicado. Dentro de un par de meses podr铆a citar The Matrix: 鈥淭u cerebro hace la traducci贸n misma. Ni siquiera veo el c贸digo. Veo una rubia, una morena y una pelirroja ". Entonces, vi toda la informaci贸n necesaria en un archivo sin herramientas adicionales.
La ventaja es que la salida se puede controlar: existen diferentes niveles de registro que determinan qu茅 informaci贸n se mostrar谩 y cu谩l no. El nivel se puede ajustar incluso para cada l铆nea individualmente a trav茅s del m茅todo de biblioteca incorporado. Al mismo tiempo, conocer el orden de las llamadas dentro de las bibliotecas de prueba y auxiliares no es superfluo, es m谩s f谩cil detectar el momento del error.
Utilizando DSL Robot Framework como nuestra herramienta principal, trabajamos durante unos seis meses. Durante este tiempo, cambi茅 de preferencias personales de Atom a VSCode, pero esto no cambi贸 la esencia del enfoque.
Sin embargo, el proyecto se estaba desarrollando. En la iteraci贸n final, la biblioteca auxiliar para trabajar con la base de datos totaliz贸 6.700 l铆neas de c贸digo en un Robot Framework puro. Con tal escala de la base del c贸digo, se ha vuelto dif铆cil de mantener, refactorizando los recursos requeridos que no fueron asignados.
La 煤ltima palabra en la aplicaci贸n del primer enfoque pertenec铆a a los negocios. El cliente de nuestro proyecto tambi茅n trabaj贸 con otros equipos en tareas relacionadas. En una de las pistas paralelas, vio, desde su punto de vista, una opci贸n m谩s efectiva e ilustrativa para usar Robot Framework, que se comenz贸 a implementar espec铆ficamente para la administraci贸n.
Segundo enfoque
El segundo enfoque fue el desarrollo de pruebas en Python junto con Robot Framework. En lugar de crear todo en la sintaxis de DSL Robot Framework, comenzamos a escribir bibliotecas auxiliares y otras interacciones de bajo nivel con el producto de prueba en Python. Y el Robot Framework, de hecho, se convirti贸 en un corredor.
Dado que Python es un lenguaje puro de alto nivel, no DSL, hay m谩s opciones de estructuraci贸n, es m谩s f谩cil resolverlo todo. Como m铆nimo, puede usar el IDE de Python para ayudarlo a encontrar los mismos m茅todos (hacen lo mismo, pero se les llama de manera diferente) o incluso escribir un c贸digo para usted. Algunos datos podr铆an estar envueltos en generadores, colgar decoradores en funciones, etc. En este contexto, las herramientas del primer enfoque (Robot Framework puro) parecen bastante duras; de hecho, era el Bloc de notas con resaltado de sintaxis. Sin setters ni getters que IntelliJ escribe para ti. As铆 que estaba feliz de volver a un idioma de nivel superior. Trabajar con este enfoque es m谩s como un desarrollo normal. Es cierto que hay una mosca en la pomada. Sin baile adicional, es imposible entender lo que cay贸 dentro de Python, llamado desde RF.
Poco a poco, las primeras pruebas y bibliotecas auxiliares para nuestro subsistema comenzaron a escribirse. Durante el tiempo que pude trabajar con un nuevo enfoque, sent铆 que con otra herramienta realmente hay m谩s oportunidades. Pero, de hecho, la redacci贸n de las pruebas no ha cambiado mucho. En este proyecto en particular, dentro del c贸digo de Python, los m茅todos de biblioteca integrados de Robot Framework todav铆a se llamaban. Esto se debi贸 a los requisitos particulares del cliente para el desarrollo de pruebas. Simplemente separamos la parte ejecutable del algoritmo del caso de prueba.
Cual es mejor
Personalmente me gusta el segundo enfoque. Sin embargo, al elegir la ruta de su proyecto, vale la pena comenzar desde la tarea: qui茅n escribe las pruebas y c贸mo.
Como dije anteriormente, Python (el segundo enfoque) brinda m谩s oportunidades, pero en este caso, se necesitan personas que est茅n familiarizadas con este lenguaje en el proyecto. El Robot Framework en s铆 (y el primer enfoque) es menos exigente: puede abordarlo leyendo la documentaci贸n oficial en su DSL. Despu茅s de estudiar la gu铆a del usuario, puede crear cualquier prueba; se ver谩n bastante limpias.
Como resultado, Robot Framework y c贸mo lo usamos al principio son m谩s adecuados para los probadores manuales de ayer sin ninguna experiencia de programaci贸n expl铆cita en lenguajes de alto nivel. Incluso una persona que no est谩 muy involucrada en la programaci贸n puede escribir una prueba, simplemente llamando las palabras clave necesarias.
Sin embargo, si desea mantener la parte ejecutable separada, siguiendo el ejemplo de nuestro proyecto, y al mismo tiempo refactorizar el c贸digo en IDE amigables, el segundo enfoque es para usted.
Autor del art铆culo: Dmitry Masters
PD: Publicamos nuestros art铆culos en varios sitios Runet. Suscr铆base a nuestras p谩ginas en
VK ,
FB o
Telegram-channel para conocer todas nuestras publicaciones y otras noticias de Maxilect.