Escritura de pruebas unitarias con PHPUnit, Parte 3: Configuración XML

Last updated Nov 29, 2022

Contenido

Configuración PHPUnit XML

1 Eliminando los archivos

2 Los fundamentos del archivo de configuración

3 El archivo Bootstrap

4 Una prueba básica que falla

4 Algunas pruebas básicas para pasar

¿Hay más? (¿Siempre tiene la razón?)

En las publicaciones anteriores de esta serie, he cubierto los siguientes dos temas:

Escritura de pruebas unitarias con PHPUnit, Parte 1: La configuración. Una guía para comenzar a escribir pruebas de PHPUnit mediante el uso de un caché básico y el método de configuración del marco.
Escritura de pruebas unitarias con PHPUnit, Parte 2: El derribo. Un tutorial sobre cómo escribir pruebas unitarias que aprovechen adecuadamente los métodos de configuración y desmontaje de PHPUnit.

Cada uno de los anteriores está destinado a proporcionar una introducción sobre cómo comenzar a escribir pruebas unitarias muy básicas. Las cosas pueden volverse más complejas, especialmente a medida que crece una aplicación o un proyecto (pero eso siempre es cierto, ¿no?).

Pero para asegurarse de que uno esté preparado para eso, hay un componente final para las pruebas unitarias en el que creo que debemos centrarnos y es comprender el archivo de configuración PHPUnit XML (que puede haber visto en otros proyectos como phpunit.xml).

Configuración PHPUnit XML

Entonces, en esta publicación, configuraré un proyecto simple que usa PHPUnit, escribe algunas pruebas como las que ya hemos visto y aprovecha un archivo de configuración para automatizar las pruebas.

Además, haré lo que pueda para explicar mejor las partes necesarias del archivo de configuración para que pueda incluir uno en su próximo proyecto.

1 Eliminando los archivos

Antes de comenzar a escribir código comprobable, es importante conocer los archivos que se necesitarán para que el proceso funcione.

La siguiente es, más o menos, cómo organizamos las cosas desde el principio de un proyecto:

un directorio para las pruebas,
el archivo phpunit.xml

Eventualmente, también verás:

los archivos que componen el proyecto,
las pruebas que verifican dichos archivos.

En este punto, sin embargo, echemos un vistazo al archivo de configuración XML y luego intentemos ejecutar PHPUnit automáticamente sin ningún otro parámetro.

2 Los fundamentos del archivo de configuración

Primero, veamos el archivo de configuración básica:

<?xml version="1.0" encoding="UTF-8"?>

<!-- http://phpunit.de/manual/4.1/en/appendixes.configuration.html -->
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="http://schema.phpunit.de/4.1/phpunit.xsd"
         bootstrap="./tests/bootstrap.php"
         backupGlobals="false"
         colors="true"
         convertErrorsToExceptions="true"
         convertNoticesToExceptions="true"
         convertWarningsToExceptions="true"
>
  <testsuites>
    <testsuite name="AcmeTests">
      <directory>./tests</directory>
    </testsuite>
  </testsuites>

  <logging>
    <log type="coverage-text" target="php://stdout" showUncoveredFiles="true"></log>
  </logging>
</phpunit>

Ahora entendamos qué es exactamente lo que estamos viendo (aparte del XML simple).

phpunidad. El nodo principal hace el trabajo habitual de definir el esquema para el archivo XML, pero hay algunos otros componentes que nos preocupan:
- copias de seguridad globales. Esto en realidad está relacionado con una anotación que podemos hacer en nuestro código fuente. Las variables globales son algo que debemos tratar de evitar en la programación orientada a objetos, pero si opta por usar una o necesita usar una, esto le indicará a PHPUnit que maneje los valores que mantienen las variables globales (y le dará la opción de restaurar a ellos). Generalmente dejo esto como está.
- oreja. Esto es opcional, pero si opta por incluir otros archivos con sus pruebas (como traer una biblioteca simulada, parte de WordPress o una biblioteca de terceros), esto le permitirá definir la ubicación de la secuencia de comandos que necesita. ejecutar. Burlarse y traer WordPress está fuera del alcance de esta publicación, pero es algo que probablemente veremos en el futuro, ya que es útil al probar complementos. Por ahora, incluiré un cargador automático simple que básicamente agrega todos los archivos en la raíz del directorio del proyecto. La fuente completa se compartirá más adelante en esta publicación.
- colores. Si desea que la consola imprima un informe de sus pruebas y lo haga usando colores (para ayudar a identificar más fácilmente advertencias, avisos, errores, etc.), establezca esto en verdadero.
- Los siguientes son todos valores booleanos. Recomiendo establecerlos en verdadero para los informes más agresivos posibles. De esta manera, no se saldrá con la suya simplemente con avisos o advertencias mientras solo se preocupa por los errores. Esto es más un ejercicio de calidad de código que cualquier otra cosa.
  - convertErrorsToExceptions
  - convertAvisosEnExcepciones
  - convertWarningsToExceptions
Los conjuntos de pruebas están formados por colecciones de pruebas. Dado que un proyecto determinado puede tener varias pruebas, es importante asegurarse de asignar a cada suite un nombre único y hacer referencia a la ruta adecuada al grupo de pruebas. Para nuestro ejemplo, solo vamos a tener un solo conjunto de pruebas y está ubicado en el directorio de pruebas.
el registro es una característica que puede ser tan simple como imprimir datos en la consola o usar una biblioteca de terceros (como Clover) para generar informes que ayuden con la integración continua. Dado que todavía tengo que discutir esto último en cualquiera de mis publicaciones anteriores, nos quedaremos con la consola como nuestro principal método de salida. Por lo tanto, tenemos php ://stdout como nuestra única salida de registro.

Dicho todo esto, nuestro archivo XML tiene todo lo que PHPUnit necesita para ejecutarse sin ningún otro parámetro.

Recuerde, sin embargo, antes de continuar con el resto de este artículo, asumo que ha instalado PHPUnit globalmente en su sistema usando Composer. De lo contrario, revise este artículo, ya que le proporcionará instrucciones sobre cómo hacerlo.

Una vez hecho esto, puede verificar que PHPUnit esté instalado ingresando el siguiente comando en su terminal:

$ which phpunit

Y deberías ver algo como lo siguiente:

Si ve algo como lo anterior, puede ejecutar PHPUnit en cualquier lugar de su sistema.

3 El archivo Bootstrap

Antes de continuar, escribamos un archivo de arranque básico. Lo llamaremos bootstrap.php y lo colocaremos en nuestro directorio de pruebas. Incluirá lo siguiente:

<?php
// This array has a single file but could whole the contents of an entire directory.
$files = [
    dirname(__DIR__).'/AcmeCache.php',
];

foreach ($files as $file) {
    if (file_exists($file)) {
        require_once $file;
    }
}

Este es un "cargador automático" simple (que vacilante lo llamo así dado que solo está iterando a través de archivos y requiriendolos, pero funciona para nuestros propósitos).

En este punto, configuremos una prueba básica.

4 Una prueba básica que falla

Si lee algo sobre el desarrollo basado en pruebas, es probable que escuche sobre el ciclo de repetición rojo-verde. Hay mucho que decir al respecto y recomiendo leerlo, pero no es el propósito de esta publicación.

En cambio, estamos más enfocados en escribir pruebas que coincidan con lo que necesitamos hacer, ¿verdad? Así que dicho esto, hagamos lo siguiente:

cree un directorio del cual tendrá algunos archivos PHP básicos que probaremos,
en la raíz del directorio, también cree phpunit.xml y rellénelo usando el código compartido anteriormente en esta publicación
cree un directorio de pruebas donde colocaremos nuestras pruebas.

Ahora, desde la Terminal, cambie el directorio al directorio del proyecto (que ciertamente falta, por ahora) y luego simplemente ejecute php unit:

$ phpunit

Suponiendo que todo esté configurado correctamente, debería ver algo como esto:

Como no tenemos código ni pruebas, naturalmente vamos a ver el resultado anterior, ¿verdad? Entonces, escribamos una sola prueba que se ejecutará (y fallará) ya que no hay código para probar.

Primero, en el directorio de pruebas, cree un archivo llamado AcmeCacheTest.php. Y hagamos que haga algo simple como instanciar un objeto de caché que eventualmente crearemos.

<?php

namespace AcmeTests;

use PHPUnitFrameworkTestCase;
use AcmeAcmeCache;

class AcmeCacheTest extends TestCase
{
    private $cache;

    public function setUp()
    {
        $this->cache = new AcmeCache();
    }

    public function testCacheExists()
    {
        $this->assertNotNull($this->cache);
    }
}

Antes de ejecutar la prueba, tenga en cuenta que nosotros:

Asegúrese de usar PHPUnitFrameworkTestCase
Y hacer que nuestra clase amplíe TestCase

Esto es parte de lo que hace que usar PHPUnit sea tan fácil. Una vez hecho esto, ejecute el siguiente código desde la raíz de su proyecto:

$ phpunit

Después de eso, deberías ver lo siguiente:

Tenga en cuenta que esto generará una prueba fallida y le dirá dónde se encontró el problema, el archivo y la línea.

Para arreglar esto, necesitamos escribir una clase:

<?php

namespace Acme;

class AcmeCache
{
    private $duration;

    public function __construct()
    {
        $this->duration = 43200;
    }

    public function setDuration(int $duration)
    {
        $this->duration = $duration;
    }

    public function getDuration(): int
    {
        return $this->duration;
    }
}

4 Algunas pruebas básicas para pasar

La prueba de aprobación básica (que se basará en el código anterior) incluirá lo siguiente:

un archivo con espacio de nombres,
representará un caché simple,
PHPUnit lo cargará automáticamente utilizando el archivo bootstrap.php compartido anteriormente
y tendrá una duración establecida en su constructor junto con un setter y getter para el valor

Primero, probemos que podemos configurar la clase y que no es nula. Esta es una afirmación un poco innecesaria ya que sabemos que tendremos una clase correctamente instanciada, pero nos pone en el ritmo de escribir pruebas:

<?php

namespace AcmeTests;

use PHPUnitFrameworkTestCase;
use AcmeAcmeCache;

class AcmeCacheTest extends TestCase
{
    private $cache;

    public function setUp()
    {
        $this->cache = new AcmeCache();
    }

    public function testCacheExists()
    {
        $this->assertNotNull($this->cache);
    }
}

Y ejecuta la prueba:

A continuación, verifiquemos que el valor predeterminado del caché esté establecido:

<?php

namespace AcmeTests;

use PHPUnitFrameworkTestCase;
use AcmeAcmeCache;

class AcmeCacheTest extends TestCase
{
    private $cache;

    public function setUp()
    {
        $this->cache = new AcmeCache();
    }

    public function testCacheExists()
    {
        $this->assertNotNull($this->cache);
    }

    public function testDefaultCacheValue()
    {
        $this->assertSame(43200, $this->cache->getDuration());
    }
}

Al igual que con el paso anterior, ejecute las pruebas y ahora debería ver dos pruebas aprobadas:

Finalmente, probemos para ver si podemos cambiar el valor con éxito:

<?php

namespace AcmeTests;

use PHPUnitFrameworkTestCase;
use AcmeAcmeCache;

class AcmeCacheTest extends TestCase
{
    private $cache;

    public function setUp()
    {
        $this->cache = new AcmeCache();
    }

    public function testCacheExists()
    {
        $this->assertNotNull($this->cache);
    }

    public function testDefaultCacheValue()
    {
        $this->assertSame(43200, $this->cache->getDuration());
    }

    public function testSetCustomDuration()
    {
        $duration = 4200;

        $this->cache->setDuration($duration);
        $this->assertSame($duration, $this->cache->getDuration());
    }
}

Y las últimas tres pruebas de aprobación:

Y ahí lo tienes:

un archivo PHPUnit XML,
un simple arranque,
una única clase con espacio de nombres,
pruebas unitarias para cada método de la clase

De acuerdo, es simple, pero esto sienta las bases para mucho más de lo que muchas personas ya hacen con sus pruebas.

Además, le brinda algo sobre lo que construir a medida que sus habilidades de prueba se fortalecen.

¿Hay más? (¿Siempre tiene la razón?)

Finalmente, si está ansioso por sumergirse realmente en el archivo de configuración, puede leer la explicación detallada del manual.

Sin embargo, tenga en cuenta que todo lo que se describe anteriormente pretende ser lo que necesita para comenzar a configurar su propio archivo de configuración PHPUnit XML.

Fuente de grabación: tommcfarlin.com