Testing Automation

Parte 2

Browser Tests - Dusk - Selenium

¿Qué es el testing?

“Las pruebas de software (en inglés software testing) son las investigaciones empíricas y técnicas cuyo objetivo es proporcionar información objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder.”

​

Tipos de Testing (los más comunes)

Unit tests

Son usados para testear pequeñas partes del código, relativamente aisladas. En general una clase o un método.

​

Integration tests

Testean la forma en que diferentes partes del código trabajan juntas y se pasan mensajes.

​

Application tests

También llamados Acceptance Tests o Functional Tests. Prueban toda la aplicación. En general usan un driver que emula el uso del navegador.

Qué es Testing Automation?

“Consiste en el uso de software especial (casi siempre separado del software que se prueba) para controlar la ejecución de pruebas y la comparación entre los resultados obtenidos y los resultados esperados”

​

Para qué sirve?

• Asegurarnos que los cambios que hacemos en nuestra aplicación no impacten en cosas que ya hicimos
• Asegurar la calidad de la aplicación
• Enfocar el uso del tiempo del equipo de desarrollo en tareas no repetitivas

​

Ventajas

• Evitar tareas repetitivas y vicios por repetición
• Permite enfocarse en el testing manual de nuevas funcionalidades que son menos estables
• Fuerza a pensar en los casos de test y documentarlos
• Permite correr los mismos tests en distintos entornos en tiempo mínimo
• Se puede incorporar a un modelo de Integración Continua (coming soon)
• Se pueden escalar y re-utilizar para hacer test de stress

​

​

Desventajas

• Período inicial de aprendizaje y adaptación del equipo de desarrollo
• Hay que mantener la suite de tests
• Los tests se ven impactados por los cambios en la UI (existen tácticas y patrones para tolerar esto)
• El perfil de tester puede requerir habilidades técnicas avanzadas (desarrollo, diseño)

​

Browser testing

Browser Testing

• Permite realizar pruebas tanto funcionales como de integración y asegurarse de que los elementos de la página pueden utilizarse
• Usar la UI como un usuario final

​

​

Cómo se imaginan que se hace esto?

Laravel Dusk

• Provee una forma expresiva y fácil de usar automatización del Browser
• Provee una API de testing
• Por defecto usa Chrome
• Podemos configurarlo para usar otro navegador

​

Dusk Install

• Para instalarlo tenemos que agregar la dependencia usando Composer

composer require --dev laravel/dusk

• Registrar el Provider en AppServiceProvider

public function register()

{

if ($this->app->environment('local', 'testing')) {

$this->app->register(DuskServiceProvider::class);

}

}

Dusk Install

• Por último

​

php artisan dusk:install

• Nos crea la carpeta tests/Browser
• Ahí vamos a tener nuestra suite de tests de browser

Correr los tests

Para correr los tests ejecutamos

php artisan dusk

​

Container de Test

• Agregamos un nuevo container a nuestro docker-compose.yml

​

selenium:

image: selenium/standalone-chrome

​

• Esta imagen nos va a permitir correr dentro del container nuestros tests

Usando Selenium: Container del test

Laravel files

(volume)

:8000

web container (nginx)

:80

database container

:5432

app container (php)

:9000

app:9000

adminer container

:8001

:8001

selenium container

:4444

Dusk test

Test access

selenium:4444

web:80

Configuración

• En el archivo DuskTestCase.php configuramos la URL del container

​

protected function driver()

{

return RemoteWebDriver::create(

'http://selenium:4444/wd/hub', DesiredCapabilities::chrome()

);

}

• Editar .env.dusk.local

APP_URL=http://web

​

Miremos el test de ejemplo

• ExampleTest.php

​

$this->browse(function (Browser $browser) {

$browser->visit('/')

->assertSee('Laravel');

});

• Qué piensan que hace?

Hagamos que pase

• TBC

Corren los Tests y los Asserts!

Nuestro Primer Test

• Para crear nuestro primer test vamos a usar

​

php artisan dusk:make LoginTest

• Vamos a hacer los siguientes tests dentro de ese archivo:
• Poder loguearnos a la app
• Fallar la password y ver que aparezca un error
• Fallar la password muchas veces y ver que aparezca un error

​

Test - Loguearnos a la App

TBC

Test - Fallar la password y ver el error

TBC

Test - Fallar la password varias veces y ver el error

TBC

Manos a la obra

TDD

Test Driven Development

¿Qué es Test Driven Development?

TDD es una práctica de programación, dividida en 3 partes:

• Escribir las pruebas (tests)
• Escribir el código fuente
• Refactorizar el código escrito

​

​

Fue creado por

(Kent Beck)

​

Ventajas

• Código más robusto
• Nos aseguramos que todo el código que escribimos esta probado y lo podemos seguir probando cuantas veces necesitemos
• Más seguro
• Si ejecutamos los tests, estamos seguros que nada dejó de funcionar con cualquier cambio que hagamos
• Más mantenible
• Teniendo una suit de tests, podemos refactorizar el código, sabiendo que no tenemos que probar todo a mano, sino que ya tenemos codigo que prueba lo que cambiamos

​

​

Mantra - Red, Green, Refactor

• Escribo un test que falle, porque aun no tengo el código hecho
• Escribo el mínimo código para que el test pase
• Mejoro la solución, refactorizando el código

​

Nuevo Requerimiento

El cliente quiere que se realicen los siguientes renombres:

• Renombrar las vistas donde se trabaja con "Variables" a "Puntaje por calificación"
• En el listado de variables renombrar la columna asistencia a orden interno
• Estadistica (de servicios) -- se llama recopiladora

​

Decidimos entonces hacer los cambios requeridos con TDD

​

Escribo el Test

TBC

Escribo el Código

TBC

Refactor

TBC

Conclusiones

• El testing nos ayuda a ganar velocidad y asegurarnos que ciertas cosas funcionan
• Es muy difícil tener una cobertura total de la app
• Hacer testing no asegura calidad de código
• Teniendo tests de browsers, nos aseguramos que la funcionalidad testeada, en ese caso, funciona
• El usuario siempre puede probar una combinación que no cubri con los tests y romper mi app

Referencias

• https://dev.to/jackmarchant/no-excuses-write-unit-tests
• https://github.com/laravel/dusk
• https://laravel.com/docs/master/dusk
• ​

F.A.Q.

Falló la ejecución

Este error surge cuando no se ha configurado Selenium

​

​

Ir a slide configuración

Code coverage

• Los test hacen que se ejecute una parte del código de la aplicación
• Cada línea fue (o no) ejecutada
• Las líneas que no se ejecutan no fueron testeadas
• Se llama “code coverage” al % de líneas que nuestros test hacen ejecutar

Extras (Revisar)

Dusk + Laradock: Workspace Setup

​

​

​

+

# Instalador de Laravel para configurar proyecto Demo�WORKSPACE_INSTALL_LARAVEL_INSTALLER=true�...�# Dependencias necesarias para correr tests de Dusk�WORKSPACE_INSTALL_DUSK_DEPS=true

docker-compose build workspace

Dusk + Laradock: Application Setup

1. Iniciar un contenedor Workspace vía Bash e instalar Laravel
2. Agregar la dependencia laravel/dusk
3. Iniciar la instalación de Dusk
4. Crear archivo de ambiente .env.dusk.local para Dusk
5. Actualizar APP_URL=http://localhost:8000 en .env.dusk.local

​

​

​

docker-compose run workspace bash

/var/www> laravel new dusk-test�/var/www> cd dusk-test�/var/www/dusk-test> composer require --dev laravel/dusk�/var/www/dusk-test> php artisan dusk:install

/var/www/dusk-test> cp .env .env.dusk.local

Dusk + Laradock: Ejecución de Tests

Iniciar server local en container workspace y ejecutar tests de Dusk

​

# Iniciar Server en Background (php artisan serve --quiet &)�/var/www/dusk-test> serve�# alias to run Dusk tests (php artisan dusk)�/var/www/dusk-test> dusk��PHPUnit 6.4.0 by Sebastian Bergmann and contributors.��. 1 / 1 (100%)��Time: 837 ms, Memory: 6.00MB