TESTING and TDD

Sagrario Meneses
Senior Software Engineer II
@sagmmd

Test/Prueba

Acción de probar a alguien o algo para conocer sus cualidades, verificar su eficacia, saber cómo funciona o reacciona, o qué resultado produce.

Durante la construcción de un software, la etapa de mantenimiento se lleva aproximadamente el 65%

  • Mantenimiento.

  • Calidad.

  • Modularidad.

  • Abstracción.

  • Detección de fallos y/o comportamientos incorrectos.

  • Ahorro de tiempo.

  • Paz mental.

Ventajas del uso de pruebas

Estilos de pruebas

También conocido como Pruebas funcionales, es un método de pruebas, donde se trata al software cómo una caja negra, de la que se desconoce su interior, únicamente se comprueban sus salidas asegurándose de que funciona cómo se espera.

Black box

  • No es necesario acceso al código para llevar a cabo esta estrategia.

 

  • Se mantienen bien separadas las perspectivas usuario - desarrollador.

Ventajas del Black box

  • Limitada cobertura en el software.

  • Cobertura ciega ya que el tester tiene conocimiento limitado sobre la aplicación.

  • Pruebas limitadas. 

Desventajas del Black box

También conocido cómo pruebas de caja clara es un método de prueba donde, contrario al Black box, sí se tiene acceso a los componentes internos del software.

White box

  •  Eficiencia en encontrar errores.

  • Ayuda en la optimización del código.

  • Una cobertura mayor es requerida.

Ventajas del White box

  • Requiere acceso al código.

  • Es posible que no se encuentren las características no implementadas o faltantes.

  • Requiere alto nivel de conocimiento de las partes internas del software.

Desventajas del White box

Test Driven Development

El TDD es un proceso de desarrollo de software que propone la repetición de pequeños fragmentos de código en un ciclo, estableciendo los requerimientos específicos por casos de uso, de esa forma el software únicamente es mejorado para pasar las pruebas creadas para cada caso de uso.

¿Cuándo fue la primera vez que se practicó TDD?

  • Escribir las pruebas primero. 

El TDD propone 2 prácticas:

  • Refactorizar después.

1. Escribir las pruebas

2. Construir lo necesario para pasar esas pruebas.

3. Mejorar el código.

RED

GREEN

REFACTOR

  • Permite la verificación de requerimientos.

  • Detección ágil de errores.

  • Un menor costo de mantenimiento.

Ventajas en el negocio por practicar TDD

  • Diseño de arquitectura - Primero 

  • Evitar la sobre - ingeniería.

  • Confianza.

Ventajas en el desarrollo por practicar TDD

  • Inyección de dependencias.

  • Test doubles (para el aislamiento):
    Stubs, Mocks, Fakes y Spies

Técnicas para realizar pruebas unitarias en POO

class A
{
    B b;

    A(B b)
    {
        this.b = b;
    }
}

class M
{
    ...
    B b = new B();
    A a = new A(b);
}
class A
{
    B b;

    A()
    {
    }

    void setB(B b)
    {
        this.b = b;
    }
}

class M
{
    ...
    B b = new B();
    A a = new A();

    a.setB(b);
}

Inyección de dependencias

  • SUnit se desarrolló para Smalltalk
    -> JUnit -> RUnit, NUnit, PHPUnit, PerlUnit. . .

Frameworks y herramientas

Selenium

En medio del "legacy code". . .

/**
 * @param Object $object
 * @param $item
 */
public function exampleAction(Object $object, $item)
{
    foreach ($object->getCarriers() as $i => $value) {
        if ($item->getCount() > 2 && $value == 100) {
            $option = $i;
        }
    }

    //Nasty code
    //More nasty code
    //And more
    //And more
    //And more . . . 

    foreach ($object->getOtherThing() as $option => $value) {
        if ($item->getMount() > 100 && $value == 'A') {
            $item->setMountType($option);
        }
    }

    $item->setCarrier($option);
}

Sugerencias y buenas prácticas

Probar el código cómo si estuviera ya corriendo en producción.

  • Configuraciones independientes.

  • Fixtures de base de datos.

  • Enfocarse en los valores y resultados necesarios.

  • Revisar las pruebas y practicar el testing con el equipo.

  • NO crear dependencias entre las pruebas.

  • Integración continua -> Automatización de pruebas.

La refactorización es como resolver el cubo de Rubik. Se necesitan muchos pasos pequeños para lograr un objetivo mayor."

No basta con que el código funcione, los programadores que se conforman con esto no son profesionales."

Bibliografía recomendada

"Clean Code" by Robert Cecil Martin

"Working Effectively with Legacy Code" by Michael Feathers

"Test-Driven Development By Example" by Kent Beck

"Refactoring" by Kent Beck and Martin Fowler

Y recuerden, las gafas aquí significan. . .

Que no sé, nada de
testing.

Que sé, pero no lo
aplico.

Que mis test me
respaldan.

¡ G R A C I A S !

Made with Slides.com