Download ApiTestCase - Download do código-fonte ApiTestCase

ApiTestCase

Pitão

v5.3.4

Baixar

ApiTestCase

ApiTestCase é um PHPUnit TestCase que tornará sua vida como desenvolvedor de API Symfony muito mais fácil. Ele estende o Symfony WebTestCase básico com alguns recursos interessantes.

Graças ao PHP-Matcher você pode, de acordo com seu leia-me, "escrever as respostas JSON esperadas como um gangster". Nós definitivamente concordamos.

Ele também usa Alice para facilitar o carregamento de fixtures do Doctrine.

Características:

Fluxo de trabalho TDD claro para desenvolvimento de API com Symfony;
Correspondência JSON/XML com mensagens de erro claras;
Carregamento de luminárias com Alice (opcional) ;

Instalação

Supondo que você já tenha o Composer instalado globalmente:

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

E está feito! ApiTestCase está funcionando com a configuração padrão.

Uso

Fornecemos duas classes base para seus casos de teste: JsonApiTestCase e XmlApiTestCase. Escolha um com base no formato da API que você deseja criar.

Exemplo JSON

O fluxo de trabalho básico do TDD é o seguinte:

Escreva um caso de teste que envie a solicitação e use o método de afirmação assertResponse para verificar se o conteúdo da resposta corresponde às suas expectativas. Você precisa de um nome para o arquivo de resposta;
Crie o arquivo com o nome escolhido na etapa 1. e coloque o conteúdo da resposta esperado lá. Deve ser colocado em src/AppBundle/Tests/Responses/Expected/hello_world.json por exemplo.
Deixe-o vermelho.
Deixe-o verde.
Refatorar.

Vejamos um exemplo simples! Escreva o seguinte teste:

 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 ' );
    }
}

Agora defina o arquivo de resposta esperado:

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

Execute seus testes:

vendor/bin/phpunit

Seu teste deve falhar com alguns erros, provavelmente está faltando o controlador e o roteamento, então vá em frente e defina-os! Assim que você implementar seu Controller e configurar o roteamento apropriado, você poderá executar seus testes novamente:

Se o conteúdo da resposta corresponder às nossas expectativas, o console apresentará uma mensagem simples:

OK (1 tests, 2 assertions)

Caso contrário apresentará diferença de mensagens recebidas:

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

Em primeiro lugar, a função assertResponse verificará o código de resposta (200 é um código de resposta padrão) e, em seguida, verificará se o cabeçalho da resposta contém o tipo de conteúdo application/json . Ao final verificará se o conteúdo da resposta corresponde à expectativa. Às vezes você não pode prever alguns valores na resposta, por exemplo, data gerada automaticamente ou ID do banco de dados. Nenhuma mágica é necessária aqui porque o PHP-Matcher vem com uma mão amiga. Estes são apenas alguns exemplos de padrões disponíveis:

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

Verifique mais na documentação do PHP-Matcher.

Com esses padrões, sua resposta esperada será assim:

{
    "message" : " @string@ "
}

Com isso implementado, qualquer string na message principal corresponderá ao padrão. A resposta esperada mais complicada poderia ser assim:

[
    {
        "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]() "
    }
]

E corresponderá à seguinte lista de produtos:

 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 (),
    ),
)

Teste com acessórios de banco de dados

ApiTestCase está integrado com nelmio/alice . Graças a esta bela biblioteca você pode facilmente carregar seus equipamentos quando precisar deles. Você tem que definir seus fixtures e colocá-los em um diretório apropriado. Aqui está um exemplo de como definir seus fixtures e caso de uso. Para mais informações sobre como definir seus fixtures consulte a documentação da Alice.

Para usar Alice com Doctrine, você deve habilitar dois pacotes adicionais:

Symfony 4.0+

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

Agora, digamos que você tenha uma entidade mapeada do Doctrine chamada Book em sua aplicação:

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

Para carregar fixtures para o teste, você precisa definir um arquivo YAML simples em 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 esses fixtures em um teste, basta chamar um método adequado:

    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 ' );
    }

Referência de configuração

Para personalizar a configuração do seu conjunto de testes, você pode adicionar mais algumas opções ao 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 permite especificar exatamente qual classe deve ser usada para configurar o Kernel.
A variável ERESPONSE_DIR contém caminhos para a pasta com as respostas esperadas. É usado quando o resultado da API é comparado com o arquivo json existente. Se este valor não for definido, o ApiTestCase tentará adivinhar a localização das respostas, procurando as respostas em uma pasta: '../Responses' relativamente localizada à classe de teste do seu controlador.
A variável FIXTURES_DIR contém um caminho para a pasta com seus equipamentos de dados. Por padrão, se esta variável não estiver definida, ela procurará ../DataFixtures/ORM/ relativamente localizado em sua classe de teste. ApiTestCase lança RunTimeException se a pasta não existir ou se não houver arquivos para carregar.
OPEN_ERROR_IN_BROWSER é um sinalizador que ativa a exibição de erros em uma janela do navegador. O valor padrão é falso.
OPEN_BROWSER_COMMAND é um comando que será usado para abrir o navegador com uma exceção.
IS_DOCTRINE_ORM_SUPPORTED é um sinalizador que ativa o suporte à doutrina, inclui um útil carregador de acessórios de dados e purgador de banco de dados.
A variável TMP_DIR contém um caminho para a pasta temporária, onde os arquivos de log serão armazenados.
ESCAPE_JSON é um sinalizador que ativa o escape (caracteres Unicode e barras) de sua saída JSON antes de compará-la com os dados esperados. O valor padrão é falso. Este sinalizador existe apenas para compatibilidade com versões anteriores do ApiTestCase (quando ativado) e será removido em uma versão futura.

Projeto de amostra

No diretório test/ , você pode encontrar um projeto Symfony de amostra com configuração mínima necessária para usar esta biblioteca.

Teste

Para executar nosso conjunto de testes PHPUnit, execute os seguintes comandos:

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

Acompanhamento de bugs e sugestões

Se você encontrou um bug ou tem uma ótima ideia para melhorias, abra um problema neste repositório.

Versionamento

Os lançamentos serão numerados com o formato major.minor.patch .

E construído com as seguintes diretrizes.

Quebrar a compatibilidade com versões anteriores prejudica o principal.
Novas adições sem quebrar a compatibilidade com versões anteriores superam o menor.
Correções de bugs e alterações diversas prejudicam o patch.

Para obter mais informações sobre SemVer, visite o site semver.org.