Testing en Symfony

Área de Gestión de Proyectos

Adrián Alonso Vega

Objetivo

  • Implementar cultura Testing en nuestros proyectos
  • Mejora de calidad y reducir incidencias
  • Mejorar el mantenimiento de las aplicaciones
  • Decidir la estrategia de desarrollo del equipo 

¿Que implica y aporta el testing?

  • Requiere compromiso del equipo
  • Entender que aumenta el tiempo de desarrollo, pero a la larga existe retorno de inversión.
  • No solo compromiso del equipo técnico, si no de los superiores
  • Un salto de calidad personal como desarrolladores
  • Facilita Refactorings sin romper funcionalidades antiguas

¿Que implica el testing?

 

  • A veces los deadline que se establecen, por el tiempo o el alcance del desarrollo afectan a la calidad.
  • Invertir en reducir deuda técnica y mantener la batería de tests

¿A qué realizamos Testing?

  • ¿que casos de prueba conllevan mucha dedicación humana y son repetitivos?
  • ¿que funcionalidades son críticas para el cliente/usuario?
  • ¿que coste tienen asociado la automatización del caso de prueba?
  • ¿Empezar por lo que conlleva mas riesgo?

Lo ideal > 70% del código del proyecto

¿Cuando hacemos testing?

TDD  es una metodología que recomienda realizar los test antes de escribir el código que pasaría dicho test. La comunidad defensora de hacer TDD asegura que de esta forma se diseña mejor la aplicación y se garantiza una cobertura de test dado que el test está implementado.

Antes

TDD

  1. Creación de un test.
  2. Ejecución del test comprobando que el test falla.
  3. Escribir código para pasar el test.
  4. Ejecutar el test, comprobando que pasa el test.
  5. Refactorizar el código
  6. Repetir

¿Cuando hacemos testing?

Mientras se va desarrollando, de forma complementaria al desarrollo en sí, programar y ejecutar los tests ayudan a mantener la calidad de código como mencionábamos anteriormente y a asegurar el funcionamiento del software tal y como la especificación determina.

Durante

¿Cuando hacemos testing?

Después

Seguir escribiendo tests tanto para modificaciones futuras como para solución de bugs detectados a posteriori, son una buena práctica a mantener. Por una parte, a mayor cobertura de tests mayor confianza se debe tener en que seguirá el correcto funcionamiento.

Por otra parte, al detectar un error, resolverlo y añadir el test que previene que ese bug no vuelva a suceder en el futuro. Esto mejora la calidad del conjunto de tests y la estabilidad del proyecto.

Tipos de Tests

  • Unitarios: Prueban una clase. Una clase de Test por cada Clase
  • Funcionales: Ejecución de Controladores. Validar Códigos de Estado (200, 302, 403)
  • Aceptación: Satisfacen las historias de usuarios definidas como especificación del programa

Conceptos 

  1. SUT (system under testing)
  2. Aserciones
  3. Test Dobles
  4. Fixtures (Doctrine Fixtures Bundle)
  5. xUnit (PHPUnit)

Comenzar con PHPUnit

{
    "require-dev": {
        "phpunit/phpunit": "5.0.*"
    }
}
    src/
    tests/
    composer.json
    phpunit.xml

instalamos en el proyecto

jerarquía de carpetas

Comenzar con PHPUnit

class XStringsTest extends PHPUnit_Framework_TestCase{

    /**
     * Test for startWith method. 
     *
     * @test
    */
    public function testStartWith()
    {
        $xstring = new XString('hello world');
        $this->assertTrue($xstring->startWith('hello'));
        $this->assertFalse($xstring->startWith('world'));
    }

}

Ejemplo  de un TEST

Comenzar con PHPUnit

vendor/bin/phpunit --coverage-html coverage 
--coverage-text -v --debug --colors=always  
--stop-on-failure --stop-on-error 

Lanzar Tests

Fichero phpunit.xml.dist

Informe de Cobertura

SonarCube

CONTINUOUS CODE QUALITY

Estructura de un TEST

Un test tiene tres partes, que se identifican con las siglas AAA en inglés:

 

Arrange (Preparar)

Act (Actuar)

Assert (Afirmar).

Estructura de un TEST

class CalculatorTest extends \PHPUnit_Framework_TestCase
{
    public function testAdd()
    {
        // ARRANGE
        $calc = new Calculator();

        // ACT
        $result = $calc->add(30, 12);

        // ASSERT
        $this->assertEquals(42, $result);
    }
}

Estructura de un TEST

Si es dificil probar la clase quizás esta mal diseñada.

- Demasiadas dependencias (desacoplar)

- Demasiada responsabilidad (dividir en clases)

 

Los tests deben ser sencillos

 

Test Dobles

Dummy

Fake

Stubs

Mock

¿Que usar para Mockear? PHPUnit, Prophecy, Mockery, Phake, AspectMock

Da superpoderes a los test de Symfony

https://github.com/liip/LiipFunctionalTestBundle

Helpers que simplifica los tests

Facilita lanzamiento de fixtures

Permite lanzar fixtures en sqlite

Referenciar fixtures en los tests

Autenticar a un cliente

 

¿MONTAR NUESTRO PROPIO BUNDLE DE TESTING?

Enseñar DoctrineBuilderMock

LaLigaWebTestCase

Traits y Helpers para las mismas tareas

EJEMPLO

VER CENTRO DE RECURSOS

 

VER KIT SELECTOR

 

VER GASTOS

 

 

SHOW ME THE CODE

BONUS TRACK

Estrategia GIT

Gitflow: https://github.com/nvie/gitflow

Integracion Continua

JENKINS

Integracion Continua

JENKINS

Estrategia Molona

Dudas, Sugerencias, Preguntas....

Testing en Symfony

By Adrián Alonso Vega

Testing en Symfony

Introducción al Testing en LaLiga

  • 835