Test Driven Development

Curso Técnico
Test-Driven Development:
Conceptos y Herramientas
Centro de Excelencia IT

Título Presentación
NOTA: Prohibida la reproducción (total parcial) o distribución de este documento sin la autorización de ALTRAN en Españaen España
NOTA: Prohibida la reproducción (total o o parcial) o distribución de este documento sin la autorización de ALTRAN Versión: xxxx ž  Fecha: dd/mm/aaaa ž  División de Negocio ž  División de negocio
Versión: xxxx ž  Fecha: dd/mm/aaaa 1

Sumario

1.  Introducción
2.  Test-Driven Development (TDD)
3.  Herramientas
a.  Pruebas Unitarias
b.  Pruebas de Integración
c.  Pruebas de Rendimiento
d.  Calidad de Código

NOTA: Prohibida la reproducción (total o parcial) o distribución de este documento sin la autorización de ALTRAN en España Versión: xxxx ž  Fecha: dd/mm/aaaa ž  División de Negocio 2

Introducción


Introducción

Un poco de Historia
■ Años 90: Boom de las Punto Com

■ Los factores de éxito de un negocio son:
q  Capacidad de crecimiento de la empresa
q  Speed-to-market

■ Requisitos cambian constantemente
q  Necesidad de ciclos de producción más cortos

■ Métodos tradicionales de desarrollo no proporcionan buenos resultados


Introducción

Modelo de Desarrollo Tradicional

Requisitos

Análisis y
Diseño

Implementación

Pruebas

Mantenimiento


Introducción

Coste de corrección de defectos
■ Es importante corregir los defectos lo antes posible

Momento en que se detecta
Coste de reparación de
defectos en Software Requisitos Arquitectura Codificación Pruebas Post-release

Requisitos 1× 3× 5–10× 10× 10–100×
Momento en
que se Arquitectura - 1× 10× 15× 25–100×
introduce

Codificación - - 1× 10× 10–25×


Introducción

Extreme Programming
■ Metodología ágil de desarrollo creada por Kent Beck

■ Introduce múltiples releases y ciclos de vida más cortos

■ Énfasis en
q  Código: Es el producto final
q  Pruebas: Permiten detectar a tiempo los defectos y solucionarlos
q  Comunicación: Permite la colaboración entre usuarios y programadores
q  Simplicidad: Centrarse en lo realmente necesario (YAGNI)
q  Feedback: Mediante pruebas, del usuario, del equipo


Introducción

Test-Driven Development

■ Basado en los conceptos de pruebas de Extreme Programming

■ Desarrollado (o “redescubierto”) por Kent Beck

■ Énfasis en pruebas como guías del desarrollo


TDD - Introducción

Definición

■ Test-Driven Development es un proceso de desarrollo software que implica la
creación de tests para comprobar funcionalidades antes de su codificación

■ Se basa en la repetición de ciclos muy cortos de desarrollo

■ Las pruebas automáticas se crean antes del código que van a comprobar


TDD – Ciclo de Desarrollo

Ciclo de Desarrollo

■ Creación de pruebas automáticas

■ Comprobación de resultados de pruebas: Fallo

■ Codificación

■ Comprobación de resultados de pruebas: Éxito

■ Refactorización y mejora del código



Ciclo de Desarrollo



Creación de Pruebas
■ Se crea el interfaz o esqueleto del objeto a probar

■ Codificación de pruebas contra el interfaz

■ Describen la funcionalidad del objeto

■ Indicarán cuándo está terminado el desarrollo del subsistema a codificar

Interfaz
Sistema a
Test Probar



Comprobación de Pruebas: Fallo

■ Se ejecutan los test contra una implementación vacía del interfaz

■ Se comprueba que fallan

■ Es importante para comprobar que los test necesitan nuevo código



Codificación
■ Se escribe el mínimo código para que los test pasen

■ Se centra en codificar la funcionalidad probada
q  No se añade funcionalidad innecesaria
q  No se añade nada que no se vaya a probar

■ No es necesario que sea perfecto
q  Se mejorará posteriormente



Comprobación de Pruebas: Éxito
■ Se comprueba que el código cumple los test escritos

■ Proporciona seguridad sobre el proceso de desarrollo
q  El código cumple con la funcionalidad
q  Podemos modificar el código y detectar si lo “rompemos”



Refactorización y Mejora de Código
■ Cambios en código sin cambiar funcionalidad

■ Mejoras en el código y diseño
q  Legibilidad
q  Complejidad
q  Mantenibilidad
q  Extensibilidad

■ Proceso iterativo
q  Descubrimiento y aplicación de patrones



Refactorización y Mejora de Código (II)
■ Ejemplos de refactorizáción
q  Generalizar tipo
q  Extraer método
q  Extraer clase
q  Extraer interfaz
q  Pull Up / Push down


TDD - Ventajas y Riesgos

Ventajas
■ Facilita el cambio
q  Detección de fallos en funcionalidad
q  Fail fast

■ Facilita la integración
q  Los componentes funcionan unitariamente

■ Mejora el diseño del sistema
q  Separación de interfaces e implementación
q  Menos interdependencias
q  Promueve refactorización y mejora del código
q  Desarrollo lean



Ventajas (II)
■ Creación de batería de tests
q  Facilita los tests de regresión
q  Amplía la cobertura de código de los test
q  Permite la realización de integración contínua

■ Mejora la productividad
q  Evita depender de depuración de código
q  Detecta los errores lo antes posible
q  Se escribe sólo lo que se puede probar



Riesgos
■ Limitaciones de pruebas unitarias
q  No se puede probar todo
q  Pruebas no deterministas (hebras…)
q  Las pruebas pueden tener errores

■ Necesidad de pruebas de integración

■ Necesidad de tests adecuados
q  Evitar tests frágiles
q  Evitar ignorar tests
q  La misma persona crea el test y el código


Test Driven Development:
Resumen


TDD - Resumen

■ Test-Driven Development

q  Metodología de desarrollo
q  Ciclos cortos
q  Se comienza por las pruebas
q  Se desarrolla hasta que se cumplen
q  Proceso de mejora contínua


TDD - Resumen


Herramientas de Test


Herramientas de Test

Herramientas y Frameworks utilizados en TDD
Apoyan el desarrollo utilizando TDD en varios ámbitos:

■ Pruebas Unitarias

■ Pruebas de Integración

■ Pruebas de Rendimiento y Carga

■ Calidad de Código


Pruebas Unitarias


Pruebas Unitarias

Conceptos
■ Pruebas de una unidad de código fuente
q  Interfaz, clase o método
q  Evitar dependencias de otros subsistemas

■ Tests independientes entre sí
q  Tratar de aislar el comportamiento de cada componente

■ Pueden ser automatizadas o automatizadas
q  No nos planteamos pruebas manuales


Pruebas Unitarias

Ventajas

■ Ayudan a encontrar defectos lo antes posible
q  Recordemos el coste de arreglo de defectos
■ Facilita el cambio
q  Permite mejorar el código asegurándonos que funciona
■ Simplifica la integración
q  Comprueba que las piezas individuales funcionan


Pruebas Unitarias

Limitaciones

■ No pueden detectar todos los errores
q  Errores de integración
q  Problemas de concurrencia
■ Necesidad de disciplina
q  Necesario actualizar los test y no ignorarlos
■ Implican esfuerzo adicional
q  Incluirlos en planificación
q  Priorizar los casos de test


Pruebas Unitarias - xUnit

Frameworks xUnit
■ Frameworks para la ejecución automática de pruebas
q  Creado por Kent Beck

■ Disponibles en múltiples lenguajes y plataformas
q  Java, .NET, PHP, Ruby, Python, C, C++, Flex, COBOL, Groovy, Erlang, MATLAB…

■ Se basan en los mismos conceptos:
q  Assertions
q  Tests
q  Test Cases
q  Fixtures
q  Test Suites



Assertions
■ Son comprobaciones de valores y resultados

■ Si no se cumplen, finalizan el test actual

■ Registran la discrepancia de valores y el lugar donde se produjo

Result result = someOperation();

assertNotNull(result);
assertEquals("someIntAttr should be 5", 5, result.someIntAttr);
assertTrue("someBoolAttr should be true", result.someBoolAttr);



Assertions (II)
■ Definición de métodos de conveniencia
q  assertTrue / assertFalse
q  assertNull / assertNotNull
q  assertArrayEquals

■ fail(): Hace que el test falle. Útil para comprobar excepciones

try {
shouldThrowException();
fail("Should have thrown an exception");
} catch (ExceptionToCatch expected) {
// Should throw this exception
}



Tests
■ Cada una de las pruebas a realizar

■ Son métodos que utilizan aserciones para comprobar los resultados

■ Marcados con @Test (Junit 4) o su nombre comienza por test (JUnit3)

@Test
public void testSomething() {

Result result = someOperation();
assertNotNull(result);
}



Test Cases
■ Agrupación de tests
■ Son clases que contienen tests a ejecutar
■ JUnit ejecuta todos los test de un TestCase de forma predeterminada
public class SomeTest extendsTestCase {

@Test
public void test1() {
// …
}

@Test
public void test2() {
// …
}
}


Test Fixtures
■ Es el contexto en el que se ejecuta cada test en un TestCase
q  Inicializa recursos comunes a los tests
■ Utiliza cuatro anotaciones:
q  @Before
■  Se ejecuta antes de todos los test de un TestCase
■  Prepara el contexto para los test
q  @After
■  Se ejecuta después de todos los test de un TestCase
■  Libera recursos y deja el contexto como estaba antes de la ejecución
q  @BeforeClass, @AfterClass
■  Igual que @Before y @After, pero se ejecutan una sola vez por TestCase

■ Es importante mantener el contexto exactamente igual
q  El resultado de los test no debe depender de ejecuciones anteriores de otros tests
q  La ejecución de un test no debe afectar al resto


Test Fixtures (II)
public class SomeTest extendsTestCase {

@BeforeClass
protected void beforeClass() throws Exception {}

@AfterClass
protected void afterClass() throws Exception {}

@Before
protected void before() throws Exception {}

@After
protected void after() throws Exception {}

@Test
public void test1() {}

@Test
public void test2() {}
}



Test Fixtures (III)
■ Orden de ejecución

Before After
Before Test1 After Before Test2 After
Class Class



Test Suites

■ Agrupación de test cases

TestSuite suite = new TestSuite();
suite.addTestSuite(SomeTest.class);

■ Se suelen realizar agrupaciones a nivel de paquete o subsistema
q  Los paquetes superiores incluyen los suites de los inferiores
q  Estructura en árbol



Ejecución

■ Por línea de comandos
q  java org.junit.runner.JUnitCore TestClass

■ Mediante ant
q  <junit> <test name="my.test.TestCase"/> </junit>

■ Mediante maven
q  mvn test

■ Desde el entorno de desarrollo
q  Run As… JUnit Test



Recomendaciones de Diseño de Tests

■ Unitarios
■ Pequeños
■ Rápidos
■ Comprensibles
■ Independientes
■ Probar casos extremos
q  Parámetros nulos
q  Colecciones vacías
q  Manejo de errores
■ Escribir test para comprobar bugs



Fakes: Stubs y Mocks

■ Los test unitarios deben probar unidades aisladas

■ Casi siempre hay interacción con otros recursos
q  Módulos o clases internas o externas
q  Bases de Datos
q  Comunicaciones
q  …

■ No debemos realizar tests que dependan de otras
unidades que no controlemos



Fakes: Stubs y Mocks (II)

■ Solución: Utilizar objetos que simulen el funcionamiento de los objetos reales

■ Stub: Objeto que implementa un interfaz y simula un funcionamiento
q  Devuelve valores preprogramados

■ Mock: Stub que además realiza comprobaciones sobre:
q  Orden de las invocaciones
q  Parámetros utilizados
q  Condiciones



Fakes: Stubs y Mocks (III)

■ Librerías que ayudan al desarrollo con fakes
q  JMock, MockObjects, EasyMock…

■ Permiten crear un objeto que cumple un interfaz y programar sus respuestas

■ Tres fases de utilización:
q  Programación de métodos a invocar y respuestas (Grabación)
q  Uso del objeto creado (Reproducción)
q  Verificación de que se han invocado los métodos esperados
(Verificación)



Fakes: Stubs y Mocks (IV)
EasyMock mock = EasyMock.createMock(InterfaceToMock.class);

// Fase de grabación
EasyMock.expect(mock.operation1(param1, param2)).andReturn(value);
EasyMock.expect(mock.operation2(param3)).andThrow(exception);
EasyMock.replay(mock);

// Uso
mock.operation1(param1, param2); // devolverá valor programado
try {
mock.operation2(param3); // lanzará excepción programada
fail(“Debería haber lanzado excepción”);
} catch (Exception ex) {
}

// Verificación
EasyMock.verify(mock);



Fakes: Stubs y Mocks - Ventajas

■ Evita dependencias de otros sistemas
q  Pruebas más simples

■ Comprueba comportamiento, no sólo devuelve resultados
q  Orden de invocación
q  Parámetros de entrada
q  Número de llamadas

■ Permite comprobar condiciones difíciles de simular
q  Excepciones
q  Variedad de resultados posibles


Pruebas Unitarias:
Resumen


Pruebas Unitarias - Resumen

Pruebas Unitarias
■ Base de las pruebas de desarrollo
q  Tests de más bajo nivel

■ Permite ahorrar tiempo y coste detectando los errores lo antes posible

■ Su automatización nos proporciona seguridad
q  Al incorporar nueva funcionalidad
q  Ante cambios en el código

■ Importante: Diseño de tests
q  Relevantes
q  Unitarios
q  Independientes

Pruebas Unitarias - Resumen

Frameworks xUnit
■ Herramientas para la ejecución automática de tests unitarios

■ Basados en una estructura simple
q  Crear contexto
■  Crear los objetos a probar y su estado (@before, @beforeClass)
q  Ejecutar pruebas
■  Realizar operaciones (métodos @test)
■  Comprobar resultados (assertions)
q  Eliminar contexto
■  Eliminar los efectos del test y su estado (@after, @afterClass)
■  Importante mantener tests independientes entre sí


Pruebas de Integración



Conceptos
■ Pruebas de varios módulos o de todo el sistema

■ Comprobar que los módulos / sistemas están correctamente configurados y
ensamblados

■ Paso previo a pruebas de aceptación

■ Pueden ser manuales o automatizadas


Pruebas de Integración:
Bases de Datos


Pruebas de Integración – Bases de Datos

Tests con Bases de Datos
■ Necesario realizar pruebas de acceso a datos
q  Es uno de los puntos de integración más importantes de una aplicación

■ Necesidad de definir un estado consistente y conocido para las pruebas
q  Cada test espera una serie de datos en base de datos

■ Un test no debería afectar a los demás
q  El fallo de un test puede conducir a un estado inconsistente
q  Posibilidad de degradación de datos de prueba

Clase a
Test BBDD
Probar



Tests con Bases de Datos - DBUnit
■ DBUnit permite definir los datos presentes antes de cada test

■ Importación de datos desde fuentes externas
q  XML
q  Excel
q  Queries a Bases de Datos
q  …

■ Prepara la BD antes y después
q  Múltiples tipos de creación de datos y limpieza posterior
q  Permite comprobar datos manualmente tras el fallo de un test



Tests con Bases de Datos – DBUnit (II)
public class SampleTest extends DBTestCase
{
public SampleTest(String name)
{
super( name );
System.setProperty( PropertiesBasedJdbcDatabaseTester.DBUNIT_DRIVER_CLASS,
"org.hsqldb.jdbcDriver" );
System.setProperty( PropertiesBasedJdbcDatabaseTester.DBUNIT_CONNECTION_URL,
"jdbc:hsqldb:sample" );
System.setProperty( PropertiesBasedJdbcDatabaseTester.DBUNIT_USERNAME, "sa" );
System.setProperty( PropertiesBasedJdbcDatabaseTester.DBUNIT_PASSWORD, "" );
}

protected IDataSet getDataSet() throws Exception
{
return new FlatXmlDataSetBuilder().build(new FileInputStream("dataset.xml"));
}
}


Tests con Bases de Datos – Spring Test (II)
■ Spring permite englobar los test en una transacción
q  Invisible para el resto de tests
q  No altera los datos existentes

■ Muy rápido

■ Necesario que los datos estén ya presentes o incluirlos en la ejecución del test

■ Sólo se pueden comprobar los resultados desde la ejecución del test

■ Requiere un bean que implemente PlatformTransactionManager
en el contexto


Tests con Bases de Datos – Spring Test (II)

■  public class DBTest extends AbstractTransactionalSpringContextTests {
■  protected String[] getConfigLocations() { return new String[] { "/es/altran/app/hibernate/
applicationContext-hibernate.xml" }; }

■  public void test1 () {
obj.someMethod();
}


Simulación de Entorno
Servidor


Pruebas de Integración – Simulación Servidor

Simulación de Servidor

■ Simulación del entorno proporcionado por un Servidor de Aplicaciones
q  Forma parte del entorno proporcionado por el test

■ Permite aplicar las técnicas vistas anteriormente para tests unitarios

Entorno de Test

Simulación
Entorno Servidor
Sistema a
Test
Probar



Simulación de Servidor (II)

■ Ventajas
q  Más rápido
q  No implica despliegue

■ Desventajas
q  Posibles dependencias de la implementación de servidor
q  No comprueba la correcta configuración del servidor
q  No es una prueba real del entorno final



Tests Unitarios de Servlets
■ Necesario simular:
q  Contexto
q  Configuración
q  Sesión
q  Peticiones

■ Spring Test proporciona clases que simulan el entorno y peticiones:
q  MockServletContext
q  MockServletConfig
q  MockHttpSession
q  MockHttpServletRequest
q  MockHttpServletResponse



Tests unitarios de EJBs
■ Dos alternativas:

■ No usar inyección de dependencias
q  Utilizar inyección de dependencias diferente de @EJB, @Resource,
@PersistenceContext

■ Utilizar un EJB Container auto-contenido
q  No forma parte de un servidor de aplicaciones
q  Ejemplo: OpenEJB. Contiene JEE excepto servlets, JSP y JSF.



Tests de EJBs (II)
■ Usando OpenEJB

■  public class HelloBeanTest {
■  private Hello hello;

■  @Before public void bootContainer() throws Exception {
■  Properties props = new Properties();
■  props.put(Context.INITIAL_CONTEXT_FACTORY,
■  "org.apache.openejb.client.LocalInitialContextFactory");
■  Context context = new InitialContext(props); hello = (Hello)
■  context.lookup("HelloBeanLocal");
■  }
■  }


Despliegue en Servidor


Pruebas de Integración – Despliegue en Servidor

Despliegue en Servidor

■ Despliega el código a probar en un Servidor de Aplicaciones

■ Necesario utilizar otras técnicas para probar el código que está en otra JVM

Entorno de Test Entorno Servidor

Sistema a
Test
Probar



Despliegue en Servidor (II)

■ Ventajas
q  Prueba la configuración del servidor
q  Prueba más completa posible
q  Posibilidad de desplegar en distintos entornos (Desarrollo, Integración,
Preproducción, Producción)

■ Desventajas
q  Más lento: Necesario desplegar el código a probar. Importante automatización
q  Necesidad de coordinación y política de despliegues en entornos compartidos



Creación de Cliente
■ Creación de un cliente para el código desplegado
■ Ejecución del cliente en JVM distinta del servidor
■ Permite probar el propio cliente
q  Puede ser parte del entregable

■ Aplicable a:
q  Servlets
q  Servicios Web (SOAP y REST)
q  EJBs
Entorno
Entorno de Test
Servidor

Test Sistema a
Cliente
Probar


SoapUI
■ Herramienta externa para probar Servicios Web
q  Funcionalidad
q  Estrés / Carga

■ Definición de pasos de test y test suites
q  Invocación a servicio (SOAP, REST, petición HTTP, AMF, JDBC)
q  Scripting en Groovy
q  Asserts específicos: Tipo de respuesta (SOAPResponse, SOAPFault), XPath, WS-
Security, contenido…

■ Ejecutables mediante la herramienta o desde JUnit



JUnit en Servidor: JUnitEE
■ El despliegue en servidor incluye el código de tests
q  Solución invasiva

■ Despliegue de servlet que controla la ejecución de tests
q  Mediante interfaz gráfico
q  Mediante tarea Ant

■ El servlet se invoca desde el cliente que lanza la prueba

Entorno de Test Entorno Servidor

Cliente Servlet Sistema a
Tests
Tests
JUnitEE JUnitEE Tests Probar

Resumen


Pruebas de Integración – Resumen

■ Permiten probar varios componentes interconectados

■ Integración con recursos externos (BBDD)
q  Preparación del entorno

■ Integración simulando un entorno
q  Rápidas
q  No son completas

■ Integración con un entorno
q  Las más completas
q  Implican disponibilidad de un entorno para desplegar
q  Intentar ser lo menos invasivo posible

Interfaces Web


Pruebas de Integración – Interfaces Web

Pruebas de Interfaces Web
■ Las pruebas de interfaces web son las más complejas de automatizar
q  Múltiples navegadores
q  Identificación de elementos a comprobar y sobre los que realizar acciones
q  Javascript
q  AJAX

■ Dos tipos de pruebas posibles
q  Sin utilizar navegador web
q  Utilizando navegador web



Pruebas Sin Navegador

■ Interpretan el HTML devuelto por peticiones HTTP

■ Interaccionan con la aplicación web realizando peticiones HTTP y
comprobando la respuesta

Entorno
Entorno de Test
Servidor

Test Aplicación
HTTP Web



Pruebas Sin Navegador

■ Ventajas
q  Muy rápidas
q  No dependen de un navegador: Ejecutables desde cualquier cliente

■ Desventajas
q  Muy bajo nivel: Tiempo de desarrollo y mantenimiento
q  No comprueban compatibilidad de navegadores
q  Difícil probar Javascript y AJAX



Pruebas Sin Navegador - HtmlUnit
■ Simula un navegador web
q  Intenta simular distintas versiones de navegadores

■ Métodos para encontrar elementos HTML

■ Simulación de Javascript
q  Uso de motor Rhino
q  Diferencias con motores de navegadores reales



Pruebas Sin Navegador – HtmlUnit (II)
■  // Navega a página
■  WebClient webClient = new WebClient();
■  HtmlPage page = webClient.getPage("http://some_url");

■  // Obtención de elementos
■  HtmlDivision div = page.getHtmlElementById("some_div_id");
■  HtmlAnchor anchor = page.getAnchorByName("anchor_name");

■  // Formulario
■  HtmlForm form = page1.getFormByName("myform");
■  HtmlSubmitInput button = form.getInputByName("submitbutton");
■  HtmlTextInput textField = form.getInputByName("userid");
■  textField.setValueAttribute("root");
■  HtmlPage page2 = button.click();


Pruebas Con Navegador
■ Utiliza un navegador web real
q  Prueba más completa
q  Permite comprobar la compatibilidad con el navegador utilizado

■ No todas las herramientas soportan todos los navegadores
q  Importante si hay que comprobar compatibilidad

Entorno
Entorno de Test
Servidor

Test Aplicación
Navegador HTTP Web



Pruebas Con Navegador – Selenium IDE

■ Entorno de grabación y reproducción de tests

■ Ejecución como plugin de Firefox

■ Ayuda a la creación de asserts en los test

■ Grabación de tests en varios formatos



Pruebas Con Navegador – Selenium WebDriver
■ Permite enviar comandos a un Browser Driver
q  Bindings para Java, .NET, Python, Ruby, PHP…

■ El Browser Driver lanza el navegador y ejecuta los comandos enviados
q  Utiliza el soporte para automatización propio de cada navegador

■ Soporte para múltiples navegadores
q  Internet Explorer
q  Firefox
q  Chrome
q  Opera
q  Android (emulador y dispositivo)
q  iOS (emulador y dispositivo)



Entorno
Entorno de Test
Servidor
Firefox Navegador
WebDriver Firefox HTTP
Aplicación
Test
IE Navegador Web
WebDriver IE HTTP




■  WebDriver driver = new FirefoxDriver();

■  driver.get("http://www.google.com");

■  WebElement element = driver.findElement(By.name("q"));
■  element.sendKeys("Cheese!");
■  element.submit();

■  System.out.println("Page title is: " + driver.getTitle());

■  driver.quit();



Pruebas Con Navegador – Selenium Grid
■ Centraliza la ejecución de tests en varias máquinas
■ Hub
q  Tiene registrados los nodos a utilizar para las pruebas
q  Registra los distintos navegadores de cada uno de los nodos
q  Permite a los tests utilizar los navegadores de cada nodo
q  Centraliza los distintos navegadores y versiones instalados
q  Permite ejecutar tests en paralelo
■ Nodo
q  Proporciona instancias de navegadores
q  Tipo y versión de navegadores específicas



Pruebas Con Navegador – Selenium Grid

Entorno Test 1 Entorno Servidor

IE Navegador
WebDriver IE

Entorno de Entorno Selenium
Test - Cliente Hub
Aplicación
Test Selenium Hub Web
Entorno Test 2

Firefox Navegador
WebDriver Firefox

NOTA: Prohibida la reproducción (total o parcial) o distribución de este documento sin la autorización de ALTRAN en España Versión: xxxx ž  Fecha: dd/mm/aaaa ž  División de Negocio

Pruebas de Interfaces Web:
Resumen


Pruebas de Interfaces Web – Resumen

Pruebas de Interfaces Web

■ Más complejas de definir y ejecutar

■ Pruebas sin navegador
q  Menos completas
q  De bajo nivel

■ Pruebas con navegador
q  Más completas
q  Determinar si es necesario comprobar compatibilidad


Pruebas de Rendimiento



Conceptos
■ Pruebas de requisitos no funcionales

■ Pruebas dedicadas a comprobar el comportamiento del sistema ante el acceso
desde múltiples clientes

■ Varios tipos:
q  Prueba de carga: Comprobar cómo se comporta el sistema con una carga
determinada.
q  Prueba de estrés: Comprobar cuáles son los límites del sistema
q  Prueba de resistencia: Comprobar si el sistema puede soportar
la carga esperada de forma continua.
q  Pruebas “de pico”: Comprobar cómo se comporta el sistema ante
una variación repentina en la carga


JUnitPerf
■ Extensión de JUnit
■ Define decoradores para pruebas de carga y tiempo
q  TimedTest: El test falla si pasa de un límite de tiempo

■  long maxElapsedTime = 1000;
■  Test testCase = new ExampleTestCase("testOneSecondResponse");
■  Test timedTest = new TimedTest(testCase, maxElapsedTime);

q  LoadTest: El mismo test se realiza de forma concurrente, pudiendo especificar
pausas y repeteiciones

■  int users = 10; int iterations = 20; Timer timer = new ConstantTimer(1000);
■  Test testCase = new ExampleTestCase("testOneSecondResponse");
■  Test repeatedTest = new RepeatedTest(testCase, iterations);
■  Test loadTest = new LoadTest(repeatedTest, users, timer);

Pruebas de Rendimiento - JMeter

JMeter
■ Aplicación de escritorio para pruebas de carga
■ Permite probar varios tipos de recursos
q  Web (HTTP)
q  SOAP
q  JDBC
q  Web Services
q  JMS

■ Permite simular condiciones complejas de carga
■ Representación gráfica de las pruebas
■ Posibilidad de realizar tests distribuidos
■ Extensible mediante plugins



Jmeter (II)
■ Varios tipos de elementos:
q  ThreadGroup: Controlan las hebras que ejecutarán los test
■  Nº de hilos
■  Iteraciones

■  Periodo de subida
q  Samplers: Toman medidas
■  SOAP, HTTP, JDBC, Mail, JMS, LDAP, FTP…
q  Controllers: Modifican el flujo de los test
■  Bucles, aleatorio…
q  Aserciones: Realizan comprobaciones sobre los resultados
q  Listeners: Reciben e interpretan los resultados de las medidas
■  Gráficos, resúmenes, …



Jmeter (III)

ThreadGroup Thread Controller

Thread
Sampler Sistema a
Probar
Listener Assertion

Sampler

Controller


Calidad de Tests


Calidad de Tests

Cobertura de Código
■ Mide cuánto se ha probado del código fuente

■ Criterios básicos:
q  Cobertura de Líneas: Número de líneas probadas por los tests
q  Cobertura de Condicionales (Branch): Todas las condiciones (if… else) han sido
probadas

■ Permite cuantificar la cantidad de código probada
q  Puede ser engañoso
q  No se comprueban los valores posibles de las variables

■ Es una medida indicativa para centrar los esfuerzos
de desarrollo de test

Calidad de Tests

Cobertura de Código - Cobertura
■ Instrumenta el código a nivel de bytecode

■ Vuelca los resultados de las clases instrumentadas y genera informes

■ Permite introducir umbrales mínimos de cobertura

■ Se integra con Ant y Maven


Integración Contínua



Conceptos
■ Aplicación de procesos de calidad constantemente durante el desarrollo

■ Actualización frecuente desde / hacia el repositorio para evitar rehacer trabajo
q  Comprobar los test antes de subir código
q  Construcción automática del código del repositorio

■ Ventajas
q  Evita que QA sea un paso posterior a desarrollo
q  Evita errores de merge en el repositorio
q  Facilita la integración de nueva funcionalidad
■ Inconvenientes
q  Necesidad de disciplina en el desarrollo



Jenkins
■ Herramienta de integración contínua ejecutable en entorno Servlet
■ Ejecuta builds de proyectos desde el repositorio
q  Disparados por nuevas subidas, periódicamente o por otros builds
q  Puede incluir la ejecución de los test y análisis de cobertura
q  Integración con herramientas de bug tracking
q  Muestra evolución y tendencias
■ Se integra con múltiples tipos de repositorios y herramientas de construcción
q  Repositorios: SVN, CVS, Git, Mercurial, Perforce, ClearCase
q  Herramientas: Maven, Ant, scripts

Entorno QA Repositorio
de Código
Jenkins



Jenkins - Ventajas
■ Ejecuta clean builds (código existente en el repositorio)

■ Comprobación constante del repositorio, incluyendo sus ramas

■ Permite evaluar las tendencias en la evolución del desarrollo
q  Número de tests y resultados
q  Calidad de código (PMD, CheckStyle)
q  Cobertura de tests

■ Notificación de resultados

■ Extensible mediante plugins

Conclusiones


Conclusiones


■ Automatización de tests fundamental

■ Los tests son los protagonistas
q  Qué (funcionalidad) antes del cómo (implementación)
q  Condicionan el diseño
q  Validan el código creado

■ Principios aplicables a metodologías ágiles y no ágiles


Conclusiones

Herramientas disponibles
■ Pruebas Unitarias
q  Frameworks xUnit / Otros
q  Mocks
■ Integración con recursos externos
q  Bases de datos, LDAP, Mail, Sistemas Legados…
q  Importante disponer de un contexto esperado y restablecerlo.
■ Integración
q  En el sistema final o simulándolo
■ Calidad de Código
q  Cobertura de tests, convenciones de código…
■ Integración Continua
q  Construcción y pruebas automatizadas


Conclusiones

¿Qué debemos probar?

■ Funcionalidades críticas para el negocio
q  Priorizar casos de prueba
q  Cobertura de código de los test
q  Pruebas de Integración

■ Funcionalidades más utilizadas

■ Crear pruebas para los bugs conocidos
q  Pruebas de regresión


Conclusiones

¿Qué debemos tener en cuenta?

■ Diseñar para facilitar tests
q  Interfaces
q  Inyección de dependencias
q  Aislar puntos de integración

■ Posibles configuraciones
q  Desarrollo
q  Integración
q  Preproducción
q  Producción


Conclusiones

Priorización de casos de prueba – Pruebas Unitarias

■ Funcionalidad de la unidad
q  Todos los casos posibles

■ Integración con otras unidades
q  Posibles respuestas
q  Tratamiento de excepciones

■ Casos extremos

■ Código "de relleno"


Conclusiones

Priorización de casos de prueba – Pruebas de Integración

■ Funcionalidad a alto nivel
q  Operaciones más comunes
q  Abarcar funcionalidad completa

■ Respuesta ante fallos
q  Excepciones
q  Falta de respuesta
q  Resultados inesperados

■ Casos extremos


Conclusiones

Priorización de casos de prueba – Pruebas de Rendimiento

■ Validación de concurrencia
q  Comprobar que el sistema funciona con múltiples usuarios

■ Depende de la criticidad y SLAs
q  Pruebas de carga
q  Estrés
q  Resistencia


Conclusiones

Priorización de casos de prueba – Calidad y Cobertura

■ Desde el principio
q  Visibilidad de evolución

■ Son herramientas e indicadores, no verdades absolutas
q  Sentido crítico en la interpretación de las pruebas

■ Cuestión de disciplina
q  Actuar en función de los resultados


Conclusiones

Reflexiones finales
■ Si no está probado…
q  No sabes si funciona
q  Miedo al cambio
q  El coste de desarrollar se incrementa
q  No hay predecibilidad
■ Convertir en metodología
q  Inculcar la cultura de test
q  Implicar a management
q  Contar con los costes
■ La calidad se paga
q  Buena: Coste de desarrollo
q  Mala: Coste de mantenimiento, deuda tecnológica,
satisfacción del cliente

Preguntas


Gracias a todos


www.altran.es


Test Driven Development

Más contenido relacionado

La actualidad más candente

Similar a Test Driven Development

Test Driven Development