Testing¶

Instalando o PHPUnit com Composer¶

Para instalar o PHPUnit com Composer:

$ php composer.phar require --dev phpunit/phpunit

Isto adicionará a dependência para a seção require-dev do seu composer.json, e depois instalará o PHPUnit com qualquer outra dependência.

Agora você executa o PHPUnit usando:

$ vendor/bin/phpunit

Usando o arquivo PHAR¶

Depois de ter baixado o arquivo phpunit.phar , você pode usar ele para executar seus testes:

php phpunit.phar

chmod +x phpunit.phar
sudo mv phpunit.phar /usr/local/bin/phpunit
phpunit --version

Filtrando Casos de Teste¶

Quando você tem casos de teste maiores, geralmente deseja executar um subconjunto dos métodos de teste ao tentar trabalhar em um único caso com falha. Com o corredor da CLI, você pode usar uma opção para filtrar os métodos de teste:

$ phpunit --filter testSave tests/TestCase/Model/Table/ArticlesTableTest

O parâmetro filter é usado como uma expressão regular com distinção entre maiúsculas e minúsculas para filtrar quais métodos de teste executar.

Gerando Cobertura de Código¶

Você pode gerar relatórios de amostras de código a partir da linha de comando usando as ferramentas internas de cobertura de código do PHPUnit. O PHPUnit irá gerar um conjunto de arquivos HTML estáticos contendo os resultados da cobertura. Você pode gerar cobertura para um caso de teste, fazendo o seguinte:

$ phpunit --coverage-html webroot/coverage tests/TestCase/Model/Table/ArticlesTableTest

Isso colocará os resultados da cobertura no diretório webroot do seu aplicativo. Você deve conseguir visualizar os resultados acessando http://localhost/your_app/coverage.

Se você estiver usando o PHP 5.6.0 ou superior, poderá usar o phpdbg para gerar cobertura em vez do xdebug. O phpdbg geralmente é mais rápido na geração de cobertura:

$ phpdbg -qrr phpunit --coverage-html webroot/coverage tests/TestCase/Model/Table/ArticlesTableTest

Combinando Conjuntos de Testes para Plug-ins¶

Muitas vezes, seu aplicativo será composto de vários plugins. Nessas situações, pode ser bastante entediante executar testes para cada plug-in. Você pode fazer testes em execução para cada um dos plugins que compõem seu aplicativo adicionando seções adicionais <testsuite> ao arquivo phpunit.xml.dist do seu aplicativo:

<testsuites>
    <testsuite name="app">
        <directory>./tests/TestCase/</directory>
    </testsuite>

    <!-- Adicione seus pacotes de plugins -->
    <testsuite name="forum">
        <directory>./plugins/Forum/tests/TestCase/</directory>
    </testsuite>
</testsuites>

Quaisquer suítes de teste adicionais vinculados ao elemento <testsuites> serão executados automaticamente quando você usar phpunit.

Se você estiver usando <testsuites> para usar acessórios de plug-ins que você instalou com o composer, o arquivo composer.json do plugin deve adicionar o espaço para nome do fixture à seção de carregamento automático. Exemplo:

"autoload-dev": {
    "psr-4": {
        "PluginName\\Test\\Fixture\\": "tests/Fixture/"
    }
},

Conexões de Teste¶

Por padrão, o CakePHP fará o pseudônimo de cada conexão em sua aplicação. Cada conexão definida no bootstrap do seu aplicativo que não inicia com test terá um alias prefixado criado com test. As conexões com aliasing garantem que você não use acidentalmente a conexão errada nos casos de teste. O alias de conexão é transparente para o restante do seu aplicativo. Por exemplo, se você usar a conexão ‘padrão’, receberá a conexão test nos casos de teste. Se você usar a conexão ‘replica’, o conjunto de testes tentará usar ‘test_replica’.

Criando Fixtures¶

Ao criar um dispositivo elétrico, você definirá principalmente duas coisas: como a tabela é criada (quais campos fazem parte da tabela) e quais registros serão preenchidos inicialmente na tabela. Vamos criar nosso primeiro fixture, que será usado para testar nosso próprio modelo de artigo. Crie um arquivo chamado ArticlesFixture.php no seu diretório tests/Fixture, com o seguinte conteúdo:

namespace AppTestFixture;

use CakeTestSuiteFixtureTestFixture;

class ArticlesFixture extends TestFixture {

// Opcional. Configure esta propriedade para carregar fixtures // em uma fonte de dados de teste diferente public $connection = ‘test’;

public $fields = [

‘id’ => [‘type’ => ‘integer’], ‘title’ => [‘type’ => ‘string’, ‘length’ => 255, ‘null’ => false], ‘body’ => ‘text’, ‘published’ => [‘type’ => ‘integer’, ‘default’ => ‘0’, ‘null’ => false], ‘created’ => ‘datetime’, ‘modified’ => ‘datetime’, ‘_constraints’ => [

‘primary’ => [‘type’ => ‘primary’, ‘columns’ => [‘id’]]

]

]; public $records = [

[

‘title’ => ‘First Article’, ‘body’ => ‘First Article Body’, ‘published’ => ‘1’, ‘created’ => ‘2007-03-18 10:39:23’, ‘modified’ => ‘2007-03-18 10:41:31’

], [

‘title’ => ‘Second Article’, ‘body’ => ‘Second Article Body’, ‘published’ => ‘1’, ‘created’ => ‘2007-03-18 10:41:23’, ‘modified’ => ‘2007-03-18 10:43:31’

], [

‘title’ => ‘Third Article’, ‘body’ => ‘Third Article Body’, ‘published’ => ‘1’, ‘created’ => ‘2007-03-18 10:43:23’, ‘modified’ => ‘2007-03-18 10:45:31’

]

];

}

A propriedade $connection define a fonte de dados que a fixture usará. Se seu aplicativo usa várias fontes de dados, você deve fazer com que as fixtures correspondam às fontes de dados do modelo, mas prefixados com test. Por exemplo, se o seu modelo usa a fonte de dados mydb, sua fixture deve usar a fonte de dados test_mydb. Se a conexão test_mydb não existir, seus modelos usarão a fonte de dados test padrão. As fontes de dados da fixture devem ser prefixadas com test para reduzir a possibilidade de truncar acidentalmente todos os dados do seu aplicativo ao executar testes.

Usamos $fields para especificar quais campos farão parte desta tabela e como eles são definidos. O formato usado para definir esses campos é o mesmo usado com Cake\Database\Schema\Table. As chaves disponíveis para definição da tabela são:

type

Tipo de dados interno do CakePHP. Atualmente suportado:

• string: mapeia para VARCHAR ou CHAR

• uuid: mapeia para UUID

• text: mapeia para TEXT

• integer: mapeia para INT

• biginteger: mapeia para BIGINTEGER

• decimal: mapeia para DECIMAL

• float: mapeia para FLOAT

• datetime: mapeia para DATETIME

• timestamp: mapeia para TIMESTAMP

• time: mapeia para TIME

• date: mapeia para DATE

• binary: mapeia para BLOB

fixed

Usado com tipos de sequência para criar colunas CHAR em plataformas que as suportam.

length

Defina para o comprimento específico que o campo deve ter.

precision

Defina o número de casas decimais usadas nos campos flutuante e decimal.

null

Defina como true (para permitir NULLs) ou false (para desabilitar NULLs).

default

Valor padrão que o campo assume.

Podemos definir um conjunto de registros que serão preenchidos após a criação da tabela de fixtures. O formato é bastante simples, $records é uma matriz de registros. Cada item em $records deve ser uma única linha. Dentro de cada linha, deve haver uma matriz associativa das colunas e valores para a linha. Lembre-se de que cada registro na matriz $records deve ter uma chave para todos os campos especificados na matriz $fields. Se um campo para um registro específico precisar ter um valor null, basta especificar o valor dessa chave como null.

Dados Dinâmicos e Fixtures¶

Como os registros de uma fixture são declarados como uma propriedade de classe, você não pode usar funções ou outros dados dinâmicos para definir fixtures. Para resolver esse problema, você pode definir $records na função init() de sua fixture. Por exemplo, se você quiser que todos os carimbos de data e hora criados e modificados reflitam a data de hoje, faça o seguinte:

namespace AppTestFixture;

use CakeTestSuiteFixtureTestFixture;

class ArticlesFixture extends TestFixture {

public $fields = [

‘id’ => [‘type’ => ‘integer’], ‘title’ => [‘type’ => ‘string’, ‘length’ => 255, ‘null’ => false], ‘body’ => ‘text’, ‘published’ => [‘type’ => ‘integer’, ‘default’ => ‘0’, ‘null’ => false], ‘created’ => ‘datetime’, ‘modified’ => ‘datetime’, ‘_constraints’ => [

‘primary’ => [‘type’ => ‘primary’, ‘columns’ => [‘id’]],

]

];

public function init() {

$this->records = [

[

‘title’ => ‘First Article’, ‘body’ => ‘First Article Body’, ‘published’ => ‘1’, ‘created’ => date(‘Y-m-d H:i:s’), ‘modified’ => date(‘Y-m-d H:i:s’),

],

]; parent::init();

}

}

Ao substituir init() lembre-se de sempre chamar parent::init().

Importando Informações da Tabela¶

Definir o esquema nos arquivos de fixture pode ser realmente útil ao criar plug-ins ou bibliotecas se você estiver criando um aplicativo que precise ser portátil entre os fornecedores de banco de dados. Redefinir o esquema em acessórios pode se tornar difícil de manter em aplicativos maiores. Devido a isso, o CakePHP fornece a capacidade de importar o esquema de uma conexão existente e usar a definição de tabela refletida para criar a definição de tabela usada no conjunto de testes.

Vamos começar com um exemplo. Supondo que você tenha uma tabela com os artigos disponíveis no seu aplicativo, altere o exemplo de dispositivo fornecido na seção anterior (tests/Fixture/ArticlesFixture.php) para:

class ArticlesFixture extends TestFixture
{
    public $import = ['table' => 'articles'];
}

Se você deseja usar uma conexão diferente, use:

class ArticlesFixture extends TestFixture
{
    public $import = ['table' => 'articles', 'connection' => 'other'];
}

Normalmente, você também tem uma classe de tabela com sua fixture. Você também pode usar isso para recuperar o nome da tabela:

class ArticlesFixture extends TestFixture
{
    public $import = ['model' => 'Articles'];
}

Como isso usa TableRegistry::getTableLocator()->get(), ele também suporta a sintaxe do plugin.

Naturalmente, você pode importar sua definição de tabela de um modelo/tabela existente, mas ter seus registros definidos diretamente no aparelho, como foi mostrado na seção anterior. Por exemplo:

class ArticlesFixture extends TestFixture
{
    public $import = ['table' => 'articles'];
    public $records = [
        [
          'title' => 'First Article',
          'body' => 'First Article Body',
          'published' => '1',
          'created' => '2007-03-18 10:39:23',
          'modified' => '2007-03-18 10:41:31'
        ],
        [
          'title' => 'Second Article',
          'body' => 'Second Article Body',
          'published' => '1',
          'created' => '2007-03-18 10:41:23',
          'modified' => '2007-03-18 10:43:31'
        ],
        [
          'title' => 'Third Article',
          'body' => 'Third Article Body',
          'published' => '1',
          'created' => '2007-03-18 10:43:23',
          'modified' => '2007-03-18 10:45:31'
        ]
    ];
}

Finalizando, não é possível carregar/criar nenhum esquema em uma fixture. Isso é útil se você já tiver uma configuração de banco de dados de teste com todas as tabelas vazias criadas. Ao não definir $fields nem $import, um equipamento apenas inserirá seus registros e truncará os registros em cada método de teste.

Carregando Fixtures em seus Casos de Teste¶

Depois de criar suas fixtures, convém usá-los em seus casos de teste. Em cada caso de teste, você deve carregar as fixtures necessárias. Você deve carregar uma fixture para cada modelo que terá uma consulta executada nele. Para carregar a fixture, defina a propriedade $fixtures no seu modelo:

class ArticlesTest extends TestCase
{
    public $fixtures = ['app.Articles', 'app.Comments'];
}

O item acima carregará os fixtures de Article e Coment do diretório fixture do aplicativo. Você também pode carregar fixture do core do CakePHP ou plugins:

class ArticlesTest extends TestCase
{
    public $fixtures = [
        'plugin.DebugKit.Articles',
        'plugin.MyVendorName/MyPlugin.Messages',
        'core.Comments'
    ];
}

Usar o prefixo core carregará fixtures do CakePHP e, usando o nome de um plugin como prefixo, carregará o fixture do plugin nomeado.

Você pode controlar quando seus fixtures são carregados configurando Cake\TestSuite\TestCase::$autoFixtures para false e carregá-los posteriormente usando Cake\TestSuite\TestCase::loadFixtures():

class ArticlesTest extends TestCase
{
    public $fixtures = ['app.Articles', 'app.Comments'];
    public $autoFixtures = false;

    public function testMyFunction()
    {
        $this->loadFixtures('Articles', 'Comments');
    }
}

Você pode carregar fixtures em subdiretórios. O uso de vários diretórios pode facilitar a organização de suas fixtures, se você tiver um aplicativo maior. Para carregar fixtures em subdiretórios, basta incluir o nome do subdiretório no nome do fixtures:

class ArticlesTest extends CakeTestCase
{
    public $fixtures = ['app.Blog/Articles', 'app.Blog/Comments'];
}

No exemplo acima, ambos os aparelhos seriam carregados a partir de tests/Fixture/Blog/.

Criando um Método de Teste¶

Vamos agora adicionar um método para testar a função publish() na tabela Articles. Edite o arquivo tests/TestCase/Model/Table/ArticlesTableTest.php para que agora fique assim:

namespace App\Test\TestCase\Model\Table;

use App\Model\Table\ArticlesTable;
use Cake\ORM\TableRegistry;
use Cake\TestSuite\TestCase;

class ArticlesTableTest extends TestCase
{
    public $fixtures = ['app.Articles'];

    public function setUp()
    {
        parent::setUp();
        $this->Articles = TableRegistry::getTableLocator()->get('Articles');
    }

    public function testFindPublished()
    {
        $query = $this->Articles->find('published');
        $this->assertInstanceOf('Cake\ORM\Query', $query);
        $result = $query->enableHydration(false)->toArray();
        $expected = [
            ['id' => 1, 'title' => 'First Article'],
            ['id' => 2, 'title' => 'Second Article'],
            ['id' => 3, 'title' => 'Third Article']
        ];

        $this->assertEquals($expected, $result);
    }
}

Você pode ver que adicionamos um método chamado testFindPublished(). Começamos criando uma instância da classe ArticlesTable e, em seguida, executamos o método find('Published'). Em $expected, definimos o que esperamos que seja o resultado adequado (que sabemos desde que definimos quais registros são preenchidos inicialmente na tabela de artigos). Testamos que o resultado é igual à nossa expectativa usando o método assertEquals(). Veja a seção Executando Testes para obter mais informações sobre como executar seu caso de teste.

Métodos Mocks de Modelo¶

Haverá momentos em que você desejará burlar métodos nos modelos ao testá-los. Você deve usar getMockForModel para criar simulações de teste de classes de tabela. Isso evita problemas com propriedades refletidas que as burlações (mocking) normais possuem:

public function testSendingEmails()
{
    $model = $this->getMockForModel('EmailVerification', ['send']);
    $model->expects($this->once())
        ->method('send')
        ->will($this->returnValue(true));

    $model->verifyEmail('[email protected]');
}

No método tearDown(), remova o mock com:

TableRegistry::clear();

Configurando a Solicitação¶

A trait IntegrationTestTrait vem com vários métodos auxiliares para facilitar a configuração das solicitações que você enviará ao seu aplicativo em teste:

// Configura cookies
$this->cookie('name', 'Uncle Bob');

// Defina um valor na sessão
$this->session(['Auth.User.id' => 1]);

// Configura cabeçalhos
$this->configRequest([
    'headers' => ['Accept' => 'application/json']
]);

O estado definido por esses métodos auxiliares é redefinido no método tearDown().

Testando Ações que Exigem Autenticação¶

Se você estiver usando AuthComponent, precisará remover os dados da sessão que o AuthComponent usa para validar a identidade de um usuário. Você pode usar métodos auxiliares em IntegrationTestTrait para fazer isso. Supondo que você tivesse um ArticlesController que continha um método add e que exigisse autenticação com o método add, você poderia escrever os seguintes testes:

public function testAddUnauthenticatedFails()
{
    // Nenhum conjunto de dados da sessão.
    $this->get('/articles/add');

    $this->assertRedirect(['controller' => 'Users', 'action' => 'login']);
}

public function testAddAuthenticated()
{
    // Define dados da sessão
    $this->session([
        'Auth' => [
            'User' => [
                'id' => 1,
                'username' => 'testing',
                // outras chaves
            ]
        ]
    ]);
    $this->get('/articles/add');

    $this->assertResponseOk();
    // Outras asserts.
}

Testando Autenticação Stateless e APIs¶

Para testar APIs que usam autenticação sem estado, como autenticação Básica, você pode configurar a solicitação para injetar condições do ambiente ou cabeçalhos que simulam cabeçalhos de solicitação de autenticação reais.

Ao testar a autenticação Básica ou Digest, você pode adicionar as variáveis de ambiente que o PHP cria <http://php.net/manual/en/features.http-auth.php> automaticamente. Essas variáveis de ambiente usadas no adaptador de autenticação descritas em basic-authentication:

public function testBasicAuthentication()
{
    $this->configRequest([
        'environment' => [
            'PHP_AUTH_USER' => 'username',
            'PHP_AUTH_PW' => 'password',
        ]
    ]);

    $this->get('/api/posts');
    $this->assertResponseOk();
}

Se você estiver testando outras formas de autenticação, como OAuth2, poderá definir o cabeçalho de Autorização diretamente:

public function testOauthToken()
{
    $this->configRequest([
        'headers' => [
            'authorization' => 'Bearer: oauth-token'
        ]
    ]);

    $this->get('/api/posts');
    $this->assertResponseOk();
}

A chave de cabeçalhos em configRequest() pode ser usada para configurar qualquer cabeçalho HTTP adicional necessário para uma ação.

Testando Ações Protegidas por CsrfComponent ou SecurityComponent¶

Ao testar ações protegidas por SecurityComponent ou CsrfComponent, você pode ativar a geração automática de token para garantir que seus testes não falhem devido a incompatibilidades de token:

public function testAdd()
{
    $this->enableCsrfToken();
    $this->enableSecurityToken();
    $this->post('/posts/add', ['title' => 'Exciting news!']);
}

Também é importante habilitar a depuração em testes que usam tokens para impedir que o SecurityComponent pense que o token de depuração está sendo usado em um ambiente sem depuração. Ao testar com outros métodos como requireSecure(), você pode usar configRequest() para definir as variáveis de ambiente corretas:

// Falsificar conexões SSL.
$this->configRequest([
    'environment' => ['HTTPS' => 'on']
]);

Teste de Integração PSR-7 Middleware¶

O teste de integração também pode ser usado para testar todo o aplicativo PSR-7 e Middleware. Por padrão, o IntegrationTestTrait detecta automaticamente a presença de uma classe App\Application e habilita automaticamente o teste de integração do seu aplicativo. Você pode alternar esse comportamento com o método useHttpServer():

public function setUp()
{
    // Ative o teste de integração PSR-7.
    $this->useHttpServer(true);

    // Desative o teste de integração PSR-7.
    $this->useHttpServer(false);
}

Você pode personalizar o nome da classe do aplicativo usado e os argumentos do construtor, usando o método configApplication():

public function setUp()
{
    $this->configApplication('App\App', [CONFIG]);
}

Depois de ativar o modo PSR-7 e, possivelmente, configurar sua classe de aplicativo, você pode usar os recursos restantes do IntegrationTestTrait normalmente.

Você também deve tentar usar Application::bootstrap() para carregar qualquer plug-in que contenha eventos/rotas. Isso garantirá que seus eventos/rotas estejam conectados para cada caso de teste. Como alternativa, se você deseja carregar plug-ins manualmente em um teste, pode usar o método loadPlugins().

Testando com Cookies Criptografados¶

Se você usar Cake\Controller\Component\CookieComponent em seus controladores, é provável que seus cookies sejam criptografados. A partir do 3.1.7, o CakePHP fornece métodos auxiliares para interagir com cookies criptografados nos seus casos de teste:

// Defina um cookie usando o AES e a chave padrão.
$this->cookieEncrypted('my_cookie', 'Some secret values');

// Suponha que esta ação modifique o cookie.
$this->get('/bookmarks/index');

$this->assertCookieEncrypted('An updated value', 'my_cookie');

Testando Mensagens Flash¶

Se você deseja testar a presença de mensagens flash na sessão e não o HTML renderizado, pode usar enableRetainFlashMessages() em seus testes para reter mensagens flash na sessão, para poder escrever as assertions:

$this->enableRetainFlashMessages();
$this->get('/bookmarks/delete/9999');

$this->assertSession('That bookmark does not exist', 'Flash.flash.0.message');

A partir da versão 3.7.0, existem auxiliares de teste adicionais para mensagens flash:

$this->enableRetainFlashMessages();
$this->get('/bookmarks/delete/9999');

// Coloque uma mensagem flash na chave 'flash'.
$this->assertFlashMessage('Bookmark deleted', 'flash');

// Afirme a segunda mensagem flash, também na chave 'flash'.
$this->assertFlashMessageAt(1, 'Bookmark really deleted');

// Afirme uma mensagem flash na chave 'auth' na primeira posição
$this->assertFlashMessageAt(0, 'You are not allowed to enter this dungeon!', 'auth');

// Afirmar que uma mensagem flash usa o elemento error
$this->assertFlashElement('Flash/error');

// Afirme o segundo elemento de mensagem flash
$this->assertFlashElementAt(1, 'Flash/error');

Testando um Controlador Com Resposta em JSON¶

JSON é um formato amigável e comum a ser usado ao criar um serviço da web. Testar os pontos finais do seu serviço da web é muito simples com o CakePHP. Vamos começar com um exemplo simples de controlador que responde em JSON:

class MarkersController extends AppController
{
    public function initialize()
    {
        parent::initialize();
        $this->loadComponent('RequestHandler');
    }

    public function view($id)
    {
        $marker = $this->Markers->get($id);
        $this->set([
            '_serialize' => ['marker'],
            'marker' => $marker,
        ]);
    }
}

Agora, criamos o arquivo tests/TestCase/Controller/MarkersControllerTest.php e garantimos que nosso serviço da Web retorne a resposta adequada:

class MarkersControllerTest extends IntegrationTestCase
{
    public function testGet()
    {
        $this->configRequest([
            'headers' => ['Accept' => 'application/json']
        ]);
        $result = $this->get('/markers/view/1.json');

        // Check that the response was a 200
        $this->assertResponseOk();

        $expected = [
            ['id' => 1, 'lng' => 66, 'lat' => 45],
        ];
        $expected = json_encode($expected, JSON_PRETTY_PRINT);
        $this->assertEquals($expected, (string)$this->_response->getBody());
    }
}

Nós usamos a opção JSON_PRETTY_PRINT, pois o CakePHP embutido no JsonView usará essa opção quando debug estiver ativado.

Desabilitando o Tratamento de Erros de Middlewares nos Testes¶

Ao depurar testes que estão falhando porque seu aplicativo está encontrando erros, pode ser útil desativar temporariamente o middleware de manipulação de erros para permitir que o erro subjacente seja exibido. Você pode usar o método disableErrorHandlerMiddleware() para fazer isso:

public function testGetMissing()
{
    $this->disableErrorHandlerMiddleware();
    $this->get('/markers/not-there');
    $this->assertResponseCode(404);
}

No exemplo acima, o teste falharia e a mensagem de exceção subjacente e o rastreamento da pilha seriam exibidos em vez da verificação da página de erro renderizada.

Métodos Assertion¶

A característica IntegrationTestTrait fornece vários métodos de asserção que tornam as respostas de teste muito mais simples. Alguns exemplos são:

// Verifica se o código da resposta é 2xx
$this->assertResponseOk();

// Verifica se o código de resposta é 2xx/3xx
$this->assertResponseSuccess();

// Verifica se o código de resposta é 4xx
$this->assertResponseError();

// Verifica se o código de resposta 5xx
$this->assertResponseFailure();

// Verifica se a resposta tem um código específico, exemplo: 200
$this->assertResponseCode(200);

// Verifica o cabeçalho do local
$this->assertRedirect(['controller' => 'Articles', 'action' => 'index']);

// Verifica se nenhum cabeçalho de redirecionamento foi definido
$this->assertNoRedirect();

// Verifique uma parte do cabeçalho Location
$this->assertRedirectContains('/articles/edit/');

// Adicionado em 3.7.0
$this->assertRedirectNotContains('/articles/edit/');

// Verifica se conteúdo de resposta não está vazio
$this->assertResponseNotEmpty();

// Verifica conteúdo de resposta vazio
$this->assertResponseEmpty();

// Afirmar conteúdo de resposta
$this->assertResponseEquals('Yeah!');

// Afirmar que o conteúdo da resposta não é igual ao especifícado
$this->assertResponseNotEquals('No!');

// Afirmar conteúdo de resposta parcialmente
$this->assertResponseContains('You won!');
$this->assertResponseNotContains('You lost!');

// Afirmar arquivo enviado de volta
$this->assertFileResponse('/absolute/path/to/file.ext');

// Afirmar layout
$this->assertLayout('default');

// Afirme qual modelo foi renderizado (se houver)
$this->assertTemplate('index');

// Afirmar dados na sessão
$this->assertSession(1, 'Auth.User.id');

// Afirmar cabeçalho de resposta.
$this->assertHeader('Content-Type', 'application/json');
$this->assertHeaderContains('Content-Type', 'html');

// Adicionado em 3.7.0
$this->assertHeaderNotContains('Content-Type', 'xml');

// Afirmar variáveis de exibição
$user =  $this->viewVariable('user');
$this->assertEquals('jose', $user->username);

// Afirmar cookies na resposta
$this->assertCookie('1', 'thingid');

// Verifique o tipo de conteúdo
$this->assertContentType('application/json');

Além dos métodos de asserção acima, você também pode usar todas as asserções no TestSuite e os encontrados em PHPUnit.

Comparando Resultados de Teste com um Arquivo¶

Para alguns tipos de teste, pode ser mais fácil comparar o resultado de um teste com o conteúdo de um arquivo - por exemplo, ao testar a saída renderizada de uma visualização. O StringCompareTrait adiciona um método de declaração simples para essa finalidade.

O uso envolve o uso da característica, definindo o caminho base de comparação e chamando assertSameAsFile:

use Cake\TestSuite\StringCompareTrait;
use Cake\TestSuite\TestCase;

class SomeTest extends TestCase
{
    use StringCompareTrait;

    public function setUp()
    {
        $this->_compareBasePath = APP . 'tests' . DS . 'comparisons' . DS;
        parent::setUp();
    }

    public function testExample()
    {
        $result = ...;
        $this->assertSameAsFile('example.php', $result);
    }
}

O exemplo acima comparará $result com o conteúdo do arquivo APP/tests/comparisons/example.php.

Um mecanismo é fornecido para gravar/atualizar arquivos de teste, configurando a variável de ambiente UPDATE_TEST_COMPARISON_FILES, que criará e/ou atualizará os arquivos de comparação de testes à medida que forem referenciados:

phpunit
...
FAILURES!
Tests: 6, Assertions: 7, Failures: 1

UPDATE_TEST_COMPARISON_FILES=1 phpunit
...
OK (6 tests, 7 assertions)

git status
...
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   tests/comparisons/example.php

Criando um Trabalho¶

Comece criando um trabalho para seu aplicativo e conecte seu repositório para que jenkins possa acessar seu código.

Adicionar Configuração do Banco de Dados de Teste¶

Usar um banco de dados separado apenas para Jenkins geralmente é uma boa idéia, pois evita vários problemas básicos. Depois de criar um novo banco de dados em um servidor de banco de dados que jenkins pode acessar (geralmente localhost). Adicione um shell script à compilação que contém o seguinte:

cat > config/app_local.php <<'CONFIG'
<?php
return [
    'Datasources' => [
        'test' => [
            'datasource' => 'Database/Mysql',
            'host'       => 'localhost',
            'database'   => 'jenkins_test',
            'username'      => 'jenkins',
            'password'   => 'cakephp_jenkins',
            'encoding'   => 'utf8'
        ]
    ]
];
CONFIG

Descomente a seguinte linha no seu arquivo config/bootstrap.php:

//Configure::load('app_local', 'default');

Ao criar um arquivo **app_local.php **, você tem uma maneira fácil de definir configurações específicas do Jenkins. Você pode usar esse mesmo arquivo de configuração para substituir qualquer outro arquivo de configuração necessário no Jenkins.

Geralmente, é uma boa ideia eliminar e recriar o banco de dados antes de cada compilação também. Isso o isola de falhas encadeadas, onde uma construção quebrada faz com que outras falhem. Adicione outra etapa do shell script à compilação que contém o seguinte:

mysql -u jenkins -pcakephp_jenkins -e 'DROP DATABASE IF EXISTS jenkins_test; CREATE DATABASE jenkins_test';

Adicione seus Testes¶

Adicione outra etapa do shell script à sua compilação. Nesta etapa, instale suas dependências e execute os testes para seu aplicativo. Criar um arquivo de log junit ou cobertura de código geralmente é um bom bônus, pois fornece uma boa visualização gráfica dos resultados dos testes:

# Faça o download do Composer, se estiver faltando.
test -f 'composer.phar' || curl -sS https://getcomposer.org/installer | php
# Instale dependências
php composer.phar install
vendor/bin/phpunit --log-junit junit.xml --coverage-clover clover.xml

Se você usar a cobertura de código ou os resultados do JUnit, certifique-se de configurar também o Jenkins. Não configurar essas etapas significa que você não verá os resultados.

Executando uma Build¶

Agora você deve poder executar uma compilação. Verifique a saída do console e faça as alterações necessárias para obter uma compilação de aprovação.