Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Sobrevive al inframundo de los tests end-to-end...

Gustavo Marin
November 24, 2017

Sobrevive al inframundo de los tests end-to-end (Codemotion 2017)

Los test end-to-end son complejos, tediosos y muy difíciles de implementar. Durante el desarrollo de un test E2E todo va bien hasta que el menor error, que en apariencia es trivial, termina convirtiéndose en una tortura indescriptible del noveno circulo del infierno.

En esta charla veremos como desarrollar tests E2E y no morir en el intento. Veremos frameworks útiles; los errores mas comunes que te puedes encontrar; buenas practicas y los fundamentos del patrón Page Object para hacer tests comprensibles y de fácil mantenimiento.

Youtube: https://www.youtube.com/watch?v=GgJeAe90H1w

Gustavo Marin

November 24, 2017
Tweet

Other Decks in Technology

Transcript

  1. @guumaster • Test Unitarios • Tests de Integración • Tests

    de UI • Tests de Aceptación • Tests E2E Tipos de Tests
  2. @guumaster Información y Confianza • Más fiables que los tests

    unitarios • Visión más completa del funcionamiento del sistema • Detectan errores rápidamente • Comprueban que todo funciona como está diseñado • Casos de uso reales (o casi reales)
  3. @guumaster Velocidad • Ahorran mucho tiempo de pruebas manuales •

    Disminuye el tiempo entre un bug y su corrección • Acometer refactorizaciones importantes • Escalar infraestructura, no humanos • Velocidad de desarrollo más constante
  4. @guumaster Tiempo • Son lentos de ejecutar • El tiempo

    es un factor relevante • No deterministas
  5. @guumaster Percepción de Negocio • Demasiado tiempo de desarrollo y

    mantenimiento • Las ventajas a medio/largo plazo • Difícil de demostrar el valor e involucrar al Cliente
  6. @guumaster Gherkin 101 • Lenguaje no técnico y “humano” (

    aka: !developer) • Describe casos de usos de software • Reglas semántica muy simple • Pocas palabras reservadas: ◦ Feature, Background, Scenario, Scenario Outline ◦ Given, When, Then, And
  7. @guumaster • Utilizar lenguaje natural para los E2E • Documentan

    el sistema desde la perspectiva del usuario • Lenguaje compartido entre equipos ◦ Diseño, Producto y Desarrollo • Implicación del equipo completo Gherkin 101
  8. @guumaster • Los diseñamos junto a el Dueño del Producto

    ◦ pero los escribe un desarrollador • Los escribimos lenguaje natural con Gherkin • Empezamos con los "happy paths" • Hacemos los tests independientes entre sí Creación y contenido
  9. @guumaster • Favorecemos tests declarativos y menos imperativos • Cuando

    es necesario "condensamos" pasos anteriores • No exponemos detalles de implementación Creación y contenido
  10. @guumaster • Hacemos un test simple modo "sonda" ◦ el

    framework funciona y el sistema es accesible • Evitamos poner timeouts si el framework de tests lo permite • Con JavaScript usamos async/await Consejos Técnicos
  11. @guumaster • Encapsulamos las APIs de Webdriver/HTML • No hacemos

    "assertions" en los métodos del PageObjects • No usamos xpath Patrón PageObject
  12. @guumaster • Intentamos "educar" a nuestro Dueño de Producto •

    Hacemos "trampas" cuando es necesario ◦ Desarrollo local => ejecución contra entorno desplegado • No buscamos probar el 100% de la app • Complementamos con test manuales y exploratorios • Automatizamos la ejecución de los tests (Gitlab CI) Consejos generales