Entendiendo los componentes

Construir una suite de test usando WebDriver requerirá que entiendas y uses de forma efectiva diferentes componentes. Como con todo en el desarrollo de software, la gente usa diferentes términos para la misma idea. A continuación hay un desglose de cómo los términos son usados en esa descripción.

Terminología

  • API: Interfaz de Programación de Aplicaciones. Es un conjunto de “comandos” que se utilizan para manipular el WebDriver.
  • Library: Un módulo de código que contiene las APIs y el código necesario para implementarlos. Las librerías son específicas para cada lenguaje, por ejemplo ficheros .jar en Java, ficheros .dll para .NET, etc.
  • Driver: El responsable de controlar el navegador actual. La mayoría de los drivers son creados por los vendors del navegador. Los Drivers son generalmente módulos ejecutables que corren en el sistema con el propio navegador, no en el sistema ejecutando la suite de test. (Aunque esos pueden ser el mismo sistema.) NOTE: Algunas personas se refieren a los drivers como proxies.
  • Framework: Una librería adicional usada como un soporte para la suites de WebDriver. Estos frameworks pueden ser test frameworks como JUnit o NUnit. También pueden ser frameworks soportando lenguaje natural como Cucumber o Robotium. Los frameworks también pueden ser escritos y usados para cosas como la manipulación o configuración del sistema bajo la prueba, creación de datos, test oracles, etc

Las Partes y las Piezas

Como mínimo, el WebDriver habla con un navegador a través del driver. La comunicación es bidireccional: el WebDriver pasa comandos al navegador a través del driver, y recibe la información de vuelta por la misma ruta.

Basic Communication

El driver es específico para el navegador, como es ChromeDriver para Chrome/Chromium de Google, GeckoDriver para Mozilla Firefox, etc. El driver corre en el mismo sistema que el browser. Esto puede, o no puede ser, el mismo sistema donde los tests se están ejecutando.

Este simple ejemplo anterior es de comunicación directa. La comunicación con el navegador puede ser remota a través de Selenium Server o RemoteWebdriver. Éste último corre en el mismo sistema que el driver y el browser.

Remote Communication

La comunicación remota puede también hacerse usando Selenium Server o Selenium Grid, ambos a su vez hablan con el driver en el sistema anfitrión.

Remote Communication with Grid

Dónde encaja el Framework

El WebDriver tiene un trabajo y solo un trabajo: comunicarse con el navegador a través de uno de los métodos nombrados. El WebDriver no tiene que saber nada sobre testing: no sabe cómo comparar cosas, asegurar un pass o fail, y ciertamente no sabe nada acerca de reportes o sobre la gramática Given/When/Then.

Aquí es donde varios frameworks entran en juego. Como mínimo necesitarás un framework de test que compare los enlaces de idiomas, por ejempolo NUnit para .NET, JUnit para Java, RSpec para Ruby, etc.

El framework de test es responsable de correr y ejecutar tu WebDriver y los pasos de tus tests. Como tal, puedes pensar que se parece a la siguiente imagen.

Test Framework

Los frameworks o herramientas de lenguage natural como Cucumber pueden existir como parte de la caja de Test Framework de la figura de arriba, o envolver totalmente el Test Framework en su propia implementación.