Smoke Test
implementados con TestNG y Selenium
0. Índice de contenidos.
1. Entorno
Este tutorial está escrito usando el siguiente entorno:
- Hardware: Portátil Mac Book Pro 15″ (2,3 Ghz Intel Core i7, 16 GB DDR3)
- Sistema Operativo: Mac OS X Mavericks
2. Introducción
Los smoke tests son un tipo de test que nos permiten verificar que el software en conjunto no «echa humo». Es decir,
que podemos completar un recorrido típico de la aplicación sin que se detecte ningún error grave. Por lo tanto
solo miran casos positivos y no contemplan los casos en los que los usuarios puedan hacer cosas raras; así que
en ningún caso sustituyen a otros tipos de tests más exhaustivos como los unitarios y los de integración.
Se caraterizan por estar automatizados y estar relacionados con las features del proyecto. De hecho, idealmente,
contaremos con un smoke test por feature o historia de usuario del proyecto. El cual, en muchas ocasiones, determinará
el DONE de una historia.
Podemos utilizarlos para ejecutarlos siempre que queramos estar tranquilos de que la aplicación no está fallando en
ningún módulo de la interfaz de usuario como cuando vamos a pasar la aplicación al departamento de pruebas o antes y después
de desplegar una release.
Integrados con una herramienta como TestLink puede ser un radiador de información para que el cliente pueda ver el avance
de las historias de usuario de un sprint.
3. Vamos al lío
Vamos a crear nuestro primer smoke test. Lo implementaremos con TestNG y Selenium. TestNG es un framework de pruebas
basado en JUnit pero al que añade nuevas funcionalidades que lo hacen más poderoso y fácil de utilizar; y Selenium es el
framework que nos permite realizar operaciones sobre un navegador para simular la interacción del usuario con la
aplicación.
Lo primero que vamos a hacer es crear un proyecto Maven e importarlo en Eclipse.
Ahora añadimos las siguientes dependencias en el pom.xml de nuestro proyecto:
<dependency> <groupId>org.testng</groupId> <artifactId>testng</artifactId> <version>6.8.7</version> <scope>test</scope> </dependency> <dependency> <groupId>org.seleniumhq.selenium</groupId> <artifactId>selenium-java</artifactId> <version>2.39.0</version> </dependency>
Ya tenemos todo para poder implementar nuestro primer test. Vamos a crear un nuevo test JUnit con el siguiente contenido:
package com.autentia.tutoriales; import org.openqa.selenium.WebDriver; import org.openqa.selenium.firefox.FirefoxDriver; import org.testng.Assert; import org.testng.annotations.Test; public class AutentiaWebTest { @Test public void getTitleAutentiaTest() { WebDriver driver = new FirefoxDriver(); driver.get("http://www.autentia.com"); Assert.assertEquals("Autentia | Soporte a desarrollo informático", driver.getTitle()); driver.quit(); } }
Para ejecutar el test desde Eclipse antes tenemos que instalar el plugin de TestNG que lo podemos encontrar en el marketplace.
Después de reiniciar para hacer efectiva la instalación del plugin. Vamos a la clase y con botón derecho seleccionamos Run As –> TestNG Test
Al ejecutar el test podremos ver que el navegador automáticamente se abre un momento, se conecta a la página de Autentia y nos devuelve
el título de la página que está visualizando. Además muestra en verde el test en la ventana de TestNG
Este es un ejemplo muy sencillo. El API de Selenium nos permite hacer muchas más cosas como: hacer click en botones, rellenar formularios,
recuperar información de la pagina, etc…
Vamos a ilustrarlo con un ejemplo un poco más complejo. Ahora el objetivo es hacer una búsqueda en la página de Autentia por el palabra «formación»
y recuperar la última parte del camino de migas que se muestra en la página cuando finaliza la búsqueda.
@Test public void fillSearchFormAndExecute(){ WebDriver driver = new FirefoxDriver(); driver.get("http://autentia.com/?s"); WebElement search = driver.findElement(By.id("s")); search.sendKeys("formación"); search.submit(); //Esperamos 10 segundos o a que devuelva el resultado de la búsqueda (new WebDriverWait(driver, 10)).until(new ExpectedCondition<Boolean>() { public Boolean apply(WebDriver d) { return d.findElement(By.className("trail-end")).getText().startsWith("Búsqueda"); } }); Assert.assertEquals(driver.findElement(By.className("trail-end")).getText(), "Búsqueda de \"formación\""); driver.quit(); }
Como se puede leer en el código, ahora nos conectamos a la página de búsqueda, buscamos el input del formulario por su id, lo rellenamos con la palabra «formación» y hacemos submit del formulario.
Fijaos que no hemos tenido que buscar el elemento del botón, Selenium lo ha hecho por nosotros al indicarle que queremos hacer submit del formulario que contiene a nuestro elemento.
Dado que tenemos que esperar a que el servidor nos devuelva los resultados de la búsqueda, implementamos una funnción que espera a que pasen 10 segundos o a que se cumpla la condición que le establecemos,
que no es otra que se muestra el texto «Búsqueda» en el camino de migas.
Una vez estamos seguros de que la página ha cargado, recuperamos todo el contenido de la parte del camino de migas que viene especificado con la clase «trail-end» y lo comparamos con el texto que esperamos.
Si volvéis ha ejecutar la clase con el nuevo test veréis que ahora el navegador Firefox se abrirá y cerrará dos veces para satisfacer las operaciones de los test y la venta de TestNG nos mostrará que los test han pasado
con un color verde.
Esta misma prueba se puede realizar desde la consola con Maven ejecutando «mvn test»
4. Conclusiones
Como véis los smoke tests no son muy difíciles de implementar y nos aportan un grado más de testabilidad en nuestros proyectos;
pero recordad que nunca pueden sustituir a los test unitarios y de integración de nuestras aplicaciones. Os recomiendo que miréis el API de WebDriver y de WebElement para ver todo lo que se puede llegar a hacer.
Cualquier duda o sugerencia en la zona de comentarios.
Saludos.
con selenio se puede hacer pruebas de caja blanca