ApiTestCase

CasoApiTest

ApiTestCase es un TestCase de PHPUnit que hará tu vida como desarrollador de API de Symfony mucho más fácil. Amplía Symfony WebTestCase básico con algunas características interesantes.

Gracias a PHP-Matcher puedes, según su archivo Léame, "escribir las respuestas json esperadas como un gángster". Definitivamente estamos de acuerdo.

También utiliza Alice para cargar fácilmente los accesorios de Doctrine.

Características:

• Flujo de trabajo TDD claro para el desarrollo de API con Symfony;
• Coincidencia JSON/XML con mensajes de error claros;
• Accesorios cargando con Alice (opcional) ;

Instalación

Suponiendo que ya tienes Composer instalado globalmente:

composer require --dev lchrusciel/api-test-case

¡Y listo! ApiTestCase está trabajando con la configuración predeterminada.

Uso

Proporcionamos dos clases base para sus casos de prueba: JsonApiTestCase y XmlApiTestCase. Elija uno según el formato de la API que desea crear.

Ejemplo Json

El flujo de trabajo básico de TDD es el siguiente:

1. Escriba un caso de prueba que envíe la solicitud y utilice el método de aserción assertResponse para comprobar si el contenido de la respuesta coincide con sus expectativas. Necesita un nombre para el archivo de respuestas;
2. Cree el archivo con el nombre que eligió en el paso 1 y coloque allí el contenido de la respuesta esperada. Debería colocarse en src/AppBundle/Tests/Responses/Expected/hello_world.json por ejemplo.
3. Hazlo rojo.
4. Hazlo verde.
5. Refactorizar.

¡Veamos un ejemplo sencillo! Escribe la siguiente prueba:

 namespace AppBundle  Tests  Controller  HelloWorldTest ;

use ApiTestCase  JsonApiTestCase ;

class HelloWorldTest extends JsonApiTestCase
{
    public function testGetHelloWorldResponse ()
    {
        $ this -> client -> request ( ' GET ' , ' / ' );

        $ response = $ this -> client -> getResponse ();

        $ this -> assertResponse ( $ response , ' hello_world ' );
    }
}

Ahora defina el archivo de respuesta esperado:

{
    "message" : " Hello ApiTestCase World! "
}

Ejecute sus pruebas:

vendor/bin/phpunit

Su prueba debería fallar con algunos errores, probablemente le falte el controlador y el enrutamiento, ¡así que continúe y defínalos! Tan pronto como implemente su controlador y configure el enrutamiento apropiado, podrá ejecutar sus pruebas nuevamente:

Si el contenido de la respuesta coincide con nuestras expectativas, la consola presentará un mensaje simple:

OK (1 tests, 2 assertions)

De lo contrario, presentará diferencias de los mensajes recibidos:

 " Hello ApiTestCase World " does not match " Hello ApiTestCase World! " .
@@ -1,4 +1,3 @@
 {
-    " message " : " Hello ApiTestCase World! "
+    " message " : " Hello ApiTestCase World "
 }
-

En primer lugar, la función assertResponse verificará el código de respuesta (200 es un código de respuesta predeterminado), luego verificará si el encabezado de la respuesta contiene el tipo de contenido application/json . Al final comprobará si el contenido de la respuesta coincide con las expectativas. A veces no se pueden predecir algunos valores en la respuesta, por ejemplo, la fecha generada automáticamente o la identificación de la base de datos. Aquí no se necesita magia porque PHP-Matcher viene para ayudar. Estos son sólo algunos ejemplos de patrones disponibles:

• @string@
• @integer@
• @boolean@
• @array@

Consulte más información sobre la documentación de PHP-Matcher.

Con estos patrones, su respuesta esperada se verá así:

{
    "message" : " @string@ "
}

Una vez implementado esto, cualquier cadena bajo message clave coincidirá con el patrón. La respuesta esperada más complicada podría verse así:

[
    {
        "id" : " @integer@ " ,
        "name" : " Star-Wars T-shirt " ,
        "sku" : " SWTS " ,
        "price" : 5500 ,
        "sizes" : " @array@ " ,
        "created_at" : " @[email protected]() "
    },
    {
        "id" : " @integer@ " ,
        "name" : " Han Solo Mug " ,
        "sku" : " HSM " ,
        "price" : 500 ,
        "sizes" : " @array@ " ,
        "created_at" : " @[email protected]() "
    }
]

Y coincidirá con la siguiente lista de productos:

 array (
    array (
        ' id ' => 1 ,
        ' name ' => ' Star-Wars T-shirt ' ,
        ' sku ' => ' SWTS ' ,
        ' price ' => 5500 ,
        ' sizes ' => array ( ' S ' , ' M ' , ' L ' ),
        ' created_at ' => new  DateTime (),
    ),
    array (
        ' id ' => 2 ,
        ' name ' => ' Han Solo Mug ' ,
        ' sku ' => ' HSM ' ,
        ' price ' => 500 ,
        ' sizes ' => array ( ' S ' , ' L ' ),
        ' created_at ' => new  DateTime (),
    ),
)

Pruebas con accesorios de bases de datos

ApiTestCase está integrado con nelmio/alice . Gracias a esta bonita biblioteca podrás cargar fácilmente tus aparatos cuando los necesites. Tienes que definir tus dispositivos y colocarlos en un directorio apropiado. A continuación se muestra un ejemplo de cómo definir sus accesorios y su caso de uso. Para obtener más información sobre cómo definir sus dispositivos, consulte la documentación de Alice.

Para usar Alice con Doctrine, debes habilitar dos paquetes adicionales:

Symfony 4.0+

 // config/bundles.php
return [
    // ...
    
    Nelmio  Alice  Bridge  Symfony NelmioAliceBundle::class => [ ' test ' => true ],
    Fidry  AliceDataFixtures  Bridge  Symfony FidryAliceDataFixturesBundle::class => [ ' test ' => true ],
];

Ahora, digamos que tienes una entidad Doctrine asignada llamada Libro en tu aplicación:

    class Book 
    {
        private $ id ;
        private $ title ;
        private $ author ;
    
        // ... 
    }

Para cargar dispositivos para la prueba, debe definir un archivo YAML simple en src/AppBundle/Tests/DataFixtures/ORM/books.yml :

    ApiTestCaseTestEntityBook :
        book1 :
            title : " Lord of The Rings "
            author : " J. R. R. Tolkien "
        book2 :
            title : " Game of Thrones "
            price : " George R. R. Martin "

Finalmente, para usar estos dispositivos en una prueba, simplemente llame a un método adecuado:

    public function testBooksIndexAction ()
    {
        // This method require subpath to locate specific fixture file in your DataFixtures/ORM directory.
        $ this -> loadFixturesFromFile ( ' books.yml ' );  
      
        // There is another method that allows you to load fixtures from directory.
        $ this -> loadFixturesFromDirectory ( ' big_library ' );
    }

Referencia de configuración

Para personalizar la configuración de su conjunto de pruebas, puede agregar algunas opciones más a phpunit.xml:

< php >
    < server name = " KERNEL_CLASS " value = " AcmeKernel " />
    < server name = " EXPECTED_RESPONSE_DIR " value = " /path/to/expected/responses/ " />
    < server name = " FIXTURES_DIR " value = " /path/to/DataFixtures/ORM/ " />
    < server name = " OPEN_ERROR_IN_BROWSER " value = " true/false " />
    < server name = " OPEN_BROWSER_COMMAND " value = " open %s " />
    < server name = " IS_DOCTRINE_ORM_SUPPORTED " value = " true/false " />
    < server name = " TMP_DIR " value = " /tmp/path/to/temporary/folder/ " />
    < server name = " ESCAPE_JSON " value = " true/false " />
</ php >

• KERNEL_CLASS le permite especificar exactamente qué clase se debe utilizar para configurar el Kernel.
• La variable ERESPONSE_DIR contiene rutas a la carpeta con las respuestas esperadas. Se utiliza cuando el resultado de la API se compara con el archivo json existente. Si este valor no está establecido, ApiTestCase intentará adivinar la ubicación de las respuestas, buscando las respuestas en una carpeta: '../Responses' ubicada relativamente a la clase de prueba de su controlador.
• La variable FIXTURES_DIR contiene una ruta a la carpeta con sus datos fijos. De forma predeterminada, si esta variable no está configurada, buscará ../DataFixtures/ORM/ ubicado relativamente a su clase de prueba. ApiTestCase lanza RunTimeException si la carpeta no existe o no habrá ningún archivo para cargar.
• OPEN_ERROR_IN_BROWSER es una bandera que activa la visualización de errores en una ventana del navegador. El valor predeterminado es falso.
• OPEN_BROWSER_COMMAND es un comando que se utilizará para abrir el navegador con una excepción.
• IS_DOCTRINE_ORM_SUPPORTED es una bandera que activa el soporte de doctrina, que incluye un práctico cargador de dispositivos de datos y un purgador de bases de datos.
• La variable TMP_DIR contiene una ruta a la carpeta temporal, donde se almacenarán los archivos de registro.
• ESCAPE_JSON es una bandera que activa el escape (caracteres Unicode y barras) de su salida JSON antes de compararla con los datos esperados. El valor predeterminado es falso. Esta marca solo existe por compatibilidad con versiones anteriores de ApiTestCase (cuando está activada) y se eliminará en una versión futura.

Proyecto de muestra

En el directorio test/ , puede encontrar un proyecto Symfony de muestra con la configuración mínima requerida para usar esta biblioteca.

Pruebas

Para ejecutar nuestro conjunto de pruebas PHPUnit, ejecute los siguientes comandos:

composer install
test/app/console doctrine:database:create
test/app/console doctrine:schema:create
vendor/bin/phpunit

Seguimiento de errores y sugerencias

Si encontró un error o tiene una gran idea para mejorar, abra un problema en este repositorio.

Versionado

Las versiones se numerarán con el formato major.minor.patch .

Y construido con las siguientes pautas.

• Romper la compatibilidad con versiones anteriores afecta a la mayoría.
• Las nuevas incorporaciones sin romper la compatibilidad con versiones anteriores superan al menor.
• Las correcciones de errores y cambios varios modifican el parche.

Para obtener más información sobre SemVer, visite el sitio web semver.org.

Licencia MIT

La licencia se puede encontrar aquí.

Autores

La biblioteca fue creada originalmente por:

• Łukasz Chruściel
• Michał Marcinkowski
• Paweł Jędrzejewski
• Arkadiusz Cracovia

en la empresa Lakion en el repositorio https://github.com/Lakion/ApiTestCase.

Ver la lista de contribuyentes.