Como cualquier sistema de software, tiene una arquitectura que puede facilitar o no la extensión, reuso y modificación.
.jpg) |
| Arquitectura del Sistema de pruebas automáticas |
Una arquitectura compartida
Algunas familias de herramientas de prueba (como Mercury, Rational, Silk y TestComplete) están pensadas para resolver toda la problemática de la prueba y tienen la arquitectura definida por el fabricante.En otros casos (como Selenium, FitNesse, Cucumber y RobotFramework) las herramientas resuelven sólo algunos de los aspectos de la prueba. Suelen usarse combinadas con otras herramientas.
Una discusión que dejo pendiente es la correlación entre los atributos de las arquitecturas (extensión, reuso y modificación) y el origen de las herramientas: propietarias o FLOSS.
Planteo entonces por mi cuenta una arquitectura que describe muchos de los stack de prueba que conozco.
Esta arquitectura está en movimiento aún. Hace un año aproximadamente incorporé el componente Comparator por conversaciones con Nicolás Páez (él plantea un modelo ligeramente distinto parte 1/parte 2). En enero de este año, cuando estaba explicando la arquitectura, me surgió la necesidad de agregar el Editor.
Y aún tengo dudas sobre la utilidad de separar algunos componentes, como por ejemplo tener componentes separados para reflejar el mecanismo de extender el DSL, tanto del lado del Test Case como del Interpreter.
Para qué buscar una arquitectura compartida
Identificar una arquitectura común de las herramientas de prueba permitiría simplificar las interfaces y que cada producto tenga foco en su especialidad, sabiendo que otros productos se ocuparán de las restantes áreas. Esperaba que el programa de la Agile Alliance "Agile Alliance Functional Testing Tools" lograra este consenso. No encuentro que se haya publicado ese análisis, aunque hay otros temas interesantes (2008, 2012).Es también útil tener un lenguaje común para poder discutir stacks alternativos cuando se está diseñando una solución de prueba.
Los componentes
Por cada componente, describo brevemente el alcance del mismo y algunos ejemplos de su instanciación en herramientas existentes.
- Editor: cómo creo y edito mis casos de prueba. En ocasiones una herramienta ad hoc, en otros casos una herramienta genérica.
Selenium: Selenium IDE, permite grabar acciones desde la aplicación o editar los TC.
WebDriver: editor/IDE del lenguaje de programación usado.
RobotFramework: RIDE, permite editar TC en forma 'inteligente', o editores de HTML.
FIT: Word, Excel y editores de HTML.
FitNesse: wiki.
Cucumber: cualquier editor de texto.
- Test Case (TC): Repositorio de mis casos de prueba, con o sin estructura y con un lenguaje con el que escribo mis casos de prueba. Puede incorporar la posibilidad de definir términos nuevos que abstraigan complejidad.
Selenium IDE: Los casos de prueba se escriben con Selenese, básicamente un HTML con una tabla de tres columnas. La estructura de casos está dada por las suite, que es una tabla HTML con los casos.
WebDriver: No tiene forma nativa de representar los casos de prueba o la estructura. Debe usarse un Runner de otra herramienta y sintaxis de lenguaje de programación usado. Extensión usando el lenguaje de programación.
RobotFramework: HTML (tablas), TSV, reST. Permiten extender el DSL de prueba con user keywords.
FitNesse: wiki markup languaje (tablas). Permiten extender el DSL de prueba con Scenario.
Cucumber: Gherkin y permiten extender el DSL de prueba con Scenario Outlines. - Interpreter: interprete del lenguaje de TC, incluyendo mecanismos para definir o extender un DSL.
Selenium: plugin de Firefox, y se extiende con plugins adicionales.
WebDriver: la parte correspondiente a WebDriver es interpretada o compilada por el lenguaje en el que se escribieron los TC (Java, Ruby, Python, etc), y resuelto con la API provista por la biblioteca de Selenium.
RobotFramework: interprete del lenguaje propio (test data syntax), se extiende con library keywords.
FitNesse: interprete de HTML (modo compatibilidad con FIT) a través de una conversión interna entre wiki text y HTML, o directamente wiki text en el caso de SLIM. Extensión usando Fixture.
Cucumber: interprete de Gherkin más los steps creados. - Adapter: cero, uno o más capas de adaptación entre los TC interpretados y el sistema bajo prueba (System Under Test o SUT). La forma de conexión depende del tipo de prueba que se quiere hacer, por ejemplo conexión con: interfaz usuario, API REST, u objetos de la aplicación.
SUT Web: un ejemplo sería WebDriver usado para automatizar la aplicación a través de la interfaz web, más PhantonJs para simular un browser.
SUT Desktop: un ejempo es Abbot para pruebas de Java Swing o White para pruebas GUI sobre Windows usando UIAutomation. - Comparator: el mecanismo de comparación entre resultados esperados y los resultados reales. El comparador puede tener conocimiento semántico y sintáctico sobre el resultado (Output) del SUT, para poder hacer comparaciones más significativas y concisas. En este sentido puede estar ligado a los adapters. En otras casos está implementado en el Interpreter. Y también puede ser extendido.
Cucumber: la base de los comparadores corresponde a las expectations de RSpec, pero se enriquecer, por ejemplo con los Capybara Matchers.
Fitnesse: una de las diferencias entre el Interprete FIT y SLIM es los comparadores adicionales (rangos, aproximados, mayor o menor). Adicionalmente, en SLIM se pueden enriquecer con Custom Comparators. - Runner: permite correr los TC. Pueden permitir ejecutar TC secuencialmente o en paralelo; todos los TC, o algún subconjunto (los que tienen cierta marca o tag, los que han fallado, etc), o uno solo TC; indicar dependencias entre TC.
Los Runner también tiene mecanismos para indicar cuando un TC ejecutado ha sido exitoso o no y mecanismos de preparación y limpieza de las pruebas. Invocan a la generación de reportes.
Cucumber: se invoca por linea de comando y puede usarse el runner de JUnit (con cucumber-JVM)
FitNesse: se puede ejecutar las pruebas desde la wiki, por linea de comandos, por servicios REST y puede usarse el runner de JUnit. - Reporter: crea los reportes de seguimiento de los resultados de la prueba. Distintos usuarios del sistema de pruebas requieren distintos reportes: resumen al momento, evolución temporal, detalle de casos ejecutados, etc. Es este área el formato XML de JUnit es el standard de facto. Aunque varias herramientas tienen alternativas: sólo texto o HMTL. Además, se incorporan a otras herramientas para brindar visibilidad, como Jenkins o SonarQube.
Conclusiones
Los equipos de desarrollo de software pueden diseñar su sistema de pruebas automáticas en forma iterativa e incremental, de igual manera a como se desarrolla el producto. Se empieza por la forma más sencilla y se mejora cuando es necesario.
Espero que este modelo te ayude a evaluar alternativas y decidir que cambiar en cada ciclo de mejora.
Espero que este modelo te ayude a evaluar alternativas y decidir que cambiar en cada ciclo de mejora.
