Esta es la presentación que he preparado para mis compañeros de @NITSNETS en la que explico la integración del testing a todos los niveles de un proyecto y profundizo un poco más en la aplicación práctica para un entorno basado en Laravel.

1. Testing && Pizza
Cómo abordar el testing sin morir en el intento

2. Di SÍ al Testing
● Es absolutamente esencial para facilitar la identificación de errores que se han
cometido en cualquier fase del proyecto.
● Mejora las garantías sobre la fiabilidad del software y la satisfacción del
cliente.
● Gracias a esta garantía de calidad se fideliza al cliente.
● Reduce los costes de mantenimiento y ahorra tiempo de desarrollo a corto,
medio y largo plazo.
● Permite garantizar que desarrollos complementarios no afectan al software ya
publicado.

3. Principios del Testing
● No se considera el testing como una fase separada del desarrollo software,
sino como parte integral al igual que la programación.
● Los tests no añaden calidad al producto, sólo la validan.
● Dado que no hay software perfecto, siempre será posible escribir un test que
rompa algo.
● El test se debe centrar en buscar el fallo, no en probar que algo funciona. Si un
test no encuentra bugs, estos no pueden ser arreglados y entonces será el
cliente quien finalmente los encuentre.
● Por eso es complicado que un programador realice tests de su propio código.
La inercia es tender a realizar tests que no fallen.

5. Tipos de Testing
1. Test de Aceptación/Cliente: Para comprobar si el software cumple con los requisitos de
negocio del cliente.
2. Test Funcionales: Amplía los tests de aceptación y añade tests relacionados con los
tiempos de respuesta, de capacidad de carga, estrés, consistencia.
3. Test de Interfaz de Usuario: Para comprobar si el entorno gráfico del cliente representa
los elementos y apariencia gráfica deseada.
4. Test Unitarios: Comprueban funcionalidades básicas y elementales del software. Son
los encargados de revisar el código fuente.
5. Test de Integración: Deben comprobar que la integración entre las diferentes partes
del proyecto es correcta. Prueban la aplicación de manera global.
6. Test A/B: Pruebas realizadas con el proyecto ya publicado para validar cómo influyen
ciertos cambios en la tasa de conversión.

6. 2 unit tests. 0 integration tests.

7. Test A/B

8. Tests Unitarios: Cómo deben ser
1. Atómicos: Sólo deben comprobar una única funcionalidad. Cuanto más
atómico más respetará los principios SOLID: Responsabilidad Única, Abierto/Cerrado,
Sustitución de Liskov, Segregación de Interfaces e Inversión de Dependencias.
2. Independientes: Que su ejecución no sea dependiente de otros tests.
3. Inocuos: Que el comportamiento de la aplicación no se vea alterado después
de su ejecución.
4. Rápidos: Como serán muchos, se necesita que sean lo más rápidos posible,
ya que deben ser ejecutados de manera continua.
Esto coincide con el principio FIRST: Fast, Independent, Repeatable, Small y Transparent.

10. Tests Unitarios: Tipos
1. Clásico: El concepto del modelo clásico indica que primero se escribe el
código y después se escriben los tests para validar el funcionamiento del
mismo.
2. Ágil TDD (Test Driven Development): Los tests se realizan antes de escribir
el código, y deben validar los requisitos del mismo. Una vez escritos los tests,
se desarrolla la aplicación para que consiga pasar todos los tests.
3. Ágil BDD (Behauvior Driven Development): Es una ampliación de TDD, no
sólo se prueban clases, se prueban escenarios y el comportamiento de las
clases a la hora de cumplir dichos escenarios, lo cual nos ayuda a centrarnos
en lo que es verdaderamente importante para el "negocio".

11. Prevenir antes que testear
● Sé lo más limpio posible con tu código. No dejes nada a medias ni dejes código
comentado "por si acaso". Desde GIT siempre podrás recuperar código que existía en
algún momento.
● Implementa la determinación de tipos en la totalidad del código.
● Durante el desarrollo habilita todo el debug posible a nivel de servidor y cliente (notices,
warnings, etc...).
● Registra en logs toda la actividad posible: Peticitiones HTTP con sus cabeceras y
parámetros, envío de correos, consultas a base de datos, conexión con servicios
externos (PUSH, TPV, etc...)
● Utiliza herramientas que ayuden al debug: xdebug, Blackfire, PHP Debug Bar, Whoops,
etc...

12. Testing por determinación de tipos (Type Hinting)
● Cuanto más determinación de tipos, mayor test en tiempo real aplicaremos.
● La determinación de tipos nos permite que los tests encuentren antes errores.
● Nos permite conocer de manera visual que hace un método sin necesidad de
realizar un trazado.
● Acelera el desarrollo ya que mejora la comprensión del código.
● Nos obliga a tener en mente lo que vamos a programar antes de comenzar
con el código.
● Nos facilita la validación de datos ya que se encarga PHP directamente.

13. Determinación de tipos en PHP 5
<?php
namespace AppServicesDatabase;
use AppModelsModelInterface;
class Builder
{
private $table;
public function __construct($table)
{
$this->table = $table;
}
public function byIds(array $ids)
{
$this->whereIn('id', array_filter(array_map('intval', $ids)));
return $this;
}
public function __toString()
{
return $this->sql();
}
public function get(ModelInterface $model)
{
return new Collection(new Connection((string)$this), $model);
}
}

14. Determinación de tipos en PHP 7.0
<?php
namespace AppServicesDatabase;
use AppModelsModelInterface;
class Builder
{
private $table;
public function __construct(string $table)
{
$this->table = $table;
}
public function byIds(int ...$ids): self
{
$this->whereIn('id', $ids);
return $this;
}
public function __toString(): string
{
return $this->sql();
}
public function get(ModelInterface $model): Collection
{
return new Collection(new Connection((string)$this), $model);
}
}

15. Determinación de tipos en PHP 7.1
<?php
namespace AppServicesDatabase;
use AppModelsModelInterface;
class Builder
{
private $table;
public function __construct(string $table)
{
$this->table = $table;
}
public function byIds(?int ...$ids): void
{
$this->whereIn('id', array_filter($ids));
}
public function __toString(): ?string
{
return $this->sql();
}
public function get(ModelInterface $model): Collection
{
return new Collection(new Connection((string)$this), $model);
}
}

17. Tests Unitarios: BDD en Laravel 5.5
● Nos da muchas facilidades para la realización de tests de nuestro proyecto.
● Integración con PHPUnit.
● Realización de tests sobre base de datos sin alterar su contenido.
● Sencillez de tests sobre HTML o APIs.
● Muy extensible.

19. Tests Unitarios: Mi primer test (⌐■_■)
<?php
namespace Tests;
use IlluminateFoundationTestingTestCase;
use IlluminateFoundationTestingDatabaseMigrations;
use IlluminateFoundationTestingDatabaseTransactions;
use IlluminateFoundationTestingWithoutMiddleware;
class MyFirstTest extends TestCase
{
use DatabaseMigrations, DatabaseTransactions, WithoutMiddleware;
public function testHome()
{
$this->visit('/')
->assertSee('Nitsnets');
}
}

20. Tests Unitarios: Formularios
<?php
namespace Tests;
use IlluminateFoundationTestingTestCase;
class FormsTest extends TestCase
{
public function testRegister()
{
$this->visit('/auth/register')
->type('Lito', 'name')
->type('lito@nitsnets.com', 'email')
->type('123456', 'password')
->type('123456', 'password_confirmation')
->check('terms')
->press('Register')
->assertPathIs('/user/profile');
}
}

21. Tests Unitarios: Login
<?php
namespace Tests;
use IlluminateFoundationTestingTestCase;
use IlluminateFoundationTestingDatabaseTransactions;
use AppModelsUser;
class FormsTest extends TestCase
{
use DatabaseTransactions;
public function testLogin()
{
$this->visit('/auth')
->type('spam@gmail.com', 'email')
->type(spam@gmail.com, 'password')
->press('Login')
->assertSee('alert-danger');
$user = factory(User::class)->create();
$this->visit('/auth')
->type($user->email, 'email')
->type($user->password, 'password')
->press('Login')
->assertPathIs('/user/profile');
}
}

22. Tests Unitarios: Zonas Privadas
<?php
namespace Tests;
use IlluminateFoundationTestingTestCase;
use IlluminateFoundationTestingDatabaseTransactions;
use IlluminateFoundationTestingWithoutMiddleware;
use AppModelsUser;
class FormsTest extends TestCase
{
use DatabaseTransactions, WithoutMiddleware;
public function testProfile()
{
$user = factory(User::class)->create();
$this->actingAs($user)
->visit('/user/profile')
->assertSee('Welcome');
}
}

23. Tests Unitarios: API Abierta
<?php
namespace Tests;
use IlluminateFoundationTestingTestCase;
use IlluminateFoundationTestingWithoutMiddleware;
use AppModelsUser;
class ApiTest extends TestCase
{
use WithoutMiddleware;
public function testStates()
{
$json = $this->get('/locations/states')
->assertStatus(200)
->getContent();
$this->assertTrue((bool)strstr($json, 'Alicante'));
$this->assertTrue((bool)strstr($json, 'Asturias'));
$json = $this->get('/locations/states?q=Ali')
->assertStatus(200)
->getContent();
$this->assertTrue((bool)strstr($json, 'Alicante'));
$this->assertFalse((bool)strstr($json, 'Asturias'));
}
}

24. Tests Unitarios: API Cerrada
<?php
namespace Tests;
use IlluminateFoundationTestingTestCase;
use IlluminateFoundationTestingDatabaseTransactions;
use IlluminateFoundationTestingWithoutMiddleware;
use AppModelsUser;
class ApiTest extends TestCase
{
use DatabaseTransactions, WithoutMiddleware;
public function testProfile()
{
$this->get('/user/profile)
->assertStatus(500)
->assertJsonStructure(['code', 'message']);
$user = factory(User::class)->create();
$this->actingAs($user)
->get('/user/profile')
->assertStatus(200)
->assertJsonStructure(['id', 'name', 'avatar']);
}
}

25. Tests Unitarios: Configuración de Entorno
<?xml version="1.0" encoding="UTF-8"?>
<phpunit
backupGlobals="false"
backupStaticAttributes="false"
bootstrap="bootstrap/autoload.php"
colors="true"
convertErrorsToExceptions="true"
convertNoticesToExceptions="true"
convertWarningsToExceptions="true"
beStrictAboutTestsThatDoNotTestAnything="false"
processIsolation="false"
stopOnFailure="true"
>
<testsuites>
<testsuite name="Web">
<file>./tests/Web/GarageTest.php</file>
</testsuite>
<testsuite name="API">
<file>./tests/Api/ConfigurationTest.php</file>
<file>./tests/Api/LocationTest.php</file>
<file>./tests/Api/GarageTest.php</file>
<file>./tests/Api/VehicleTest.php</file>
<file>./tests/Api/UserSignupTest.php</file>
<file>./tests/Api/UserAuthTest.php</file>
<file>./tests/Api/UserTest.php</file>
<file>./tests/Api/UserVehicleTest.php</file>
<file>./tests/Api/RepairTest.php</file>
<file>./tests/Api/BudgetTest.php</file>
</testsuite>
</testsuites>
<filter>
<whitelist processUncoveredFilesFromWhitelist="true">
<directory suffix=".php">./app</directory>
<exclude>
<directory suffix=".php">./app/Http/routes</directory>
</exclude>
</whitelist>
</filter>
<logging>
<log type="junit" target="./tests/reports/phpunit.junit.xml"
logIncompleteSkipped="false" />
<log type="coverage-clover"
target="./tests/reports/phpunit.coverage.xml" />
</logging>
<php>
<env name="APP_ENV" value="testing" />
<env name="CACHE_DRIVER" value="array" />
<env name="SESSION_DRIVER" value="array" />
<env name="QUEUE_DRIVER" value="sync" />
<env name="PUSH_NOTIFICATIONS" value="false" />
<env name="MAIL_DRIVER" value="log" />
</php>
</phpunit>

26. Algunas dudas y preguntas de compañeros de diferentes departamentos

27. ● En qué parte del proyecto son más necesarios los tests?
● En todo momento, ya que no sólo testeamos código. Se debe testear las
especificaciones con el cliente, la implementación, la integración, el UX, el
rendimiento, el resultado y los cambios a/b.
● Cómo hacer para integrar los tests en proyectos en los que se necesita
infraestructura externa (base de datos, redis-cache, colas, ... )?
● Los frameworks suelen disponer de herramientas para estas tareas. Para base
de datos, por ejemplo Laravel dispone de DatabaseTransactions, y para
colas, se pasarían a ejecución síncrona desde phpunit.xml <env
name="QUEUE_DRIVER" value="sync" />
Dudas y Preguntas

28. ● Tests incluidos dentro del proyecto como o externos?
● Siempre integrados en el proyecto, deben estar disponibles para su ejecución
desde el primer momento para los nuevos desarrolladores y CI.
● Datos sobre el ahorro en costes del mantenimiento de un proyecto.
● La única manera de calcular el ahorro en un proyecto con tests es compararlo
con otro similar, tanto en tiempo de desarrollo inicial, como sobre todo, y más
importante, la cantidad y el tiempo de corrección de las incidencias que
surgen en las fases más avanzadas del proyecto y desde su publicación.
Desde mi experiencia, SIEMPRE ahorras, y sobre todo en confianza del
cliente.
Dudas y Preguntas

29. ● Saber cómo se implementa en la parte de consultoría de marketing,
arquitectura de la información, seo...
● Los tests A/B son una buena manera de aplicar y validar los cambios en
cuanto a marketing. No todos los tests son automáticos, ni todos los tests se
pueden aplicar de manera "directa". En este caso son tests de
comportamiento. Para SEO, simplemente seguir en lo posible ciertas
directrices :)
● Es costoso el mantenimiento de los tests?
● Si se realizan de manera correcta, no. Los tests deben ir avanzando con el
desarrollo y programarlos como tal. Es costoso el mantenimiento del código?
Entonces será costoso el mantenimiento de los tests.
Dudas y Preguntas

31. @lito