Escrevendo Testes Unitários com PHPUnit, Parte 2: The Tear Down

No final do mês passado, comecei a falar sobre escrever testes de unidade em PHPUnit para código baseado em WordPress. Isso incluiu principalmente a ideia de configurar o PHPUnit, a função setUp e escrever testes básicos.

Isso, no entanto, não discutiu o que eu sei sobre a função tearDown, que ainda é um recurso importante de escrever usando testes. Além disso, também há duas maneiras de considerar escrever testes para projetos do WordPress.

Nomeadamente:

1. escrever testes especificamente para plugins e funcionalidade da camada de aplicação,
2. executando testes de unidade no aplicativo WordPress.

Antes de avançar com este post em particular, porém, recomendo atualizar o que abordei até agora. Isso inclui as seguintes postagens:

1. Um ambiente de desenvolvimento WordPress (usando um gerenciador de pacotes)
2. Um IDE para desenvolvimento WordPress
3. Trabalhando com configurações de usuário no Visual Studio Code
4. Escrevendo testes de unidade com PHPUnit, parte 1: a configuração

Depois de fazer isso, volte a este post e vamos continuar discutindo a função tearDown e como são os testes de unidade no contexto do WordPress.

Testes Unitários com PHPUnit, Parte 2: A Destruição

Antes de prosseguir, lembre-se de que os desenvolvedores geralmente tratam a função setUp como o construtor e a função tearDown como um destruidor; no entanto, lembre-se de que o último nem sempre é necessário.

Aqui está uma boa regra para lembrar:

• Qualquer coisa que uma função de teste precise chamará a função setUp para que as classes necessárias sejam necessárias.
• A função tearDown nem sempre é necessária, pois a função setUp pode reinicializar uma classe.

Então, o que isso significa para a função tearDown se ela não estiver redefinindo os dados criados durante a função setUp?

1 A função de desmontagem

O melhor conselho que posso dar sobre a função tearDown é que ela deve ser usada se algo for configurado durante um dos testes que for deixado para trás.

Isso pode ser algo gravado em um banco de dados, algo gravado em um log ou, mais geralmente, algo gravado no disco rígido.

Assim, se um teste gravar um registro ou arquivo, o método tearDown será executado após um teste e deverá remover qualquer teste gravado na unidade que não faça parte do teste, mas não seja permanentemente necessário para o próximo teste ou que deve ser limpo depois de si mesmo.

Então, de certa forma, é como um destruidor, mas se você nunca usou uma linguagem que tenha um destruidor, essa nomenclatura parece irrelevante ou não faz sentido.

Um destruidor é uma função de membro especial que é chamada quando o tempo de vida de um objeto termina. O objetivo do destruidor é liberar os recursos que o objeto pode ter adquirido durante sua vida útil.

Assim, talvez seja melhor simplesmente pensar na função como uma forma de limpeza após um teste (e não no sentido de definir uma variável igual a nula, pois a função setUp pode fazer isso).

2 testes de unidade para projetos WordPress

Ao escrever testes de unidade para projetos do WordPress, temos que ter certeza de que estamos sendo claros sobre o tipo de teste de unidade sobre o qual estamos falando.

Por exemplo, o que chamarei de testes unitários clássicos ou padrão seguem a metodologia de “desenvolvimento orientado a testes" sobre a qual falarei em breve. Por outro lado, o WordPress tem seu próprio conjunto de testes de unidade para temas e afins, sobre os quais também falarei um pouco mais adiante neste post.

Mas para esta seção, achei que poderia ser útil falar um pouco sobre o primeiro em vez do segundo, para que você possa ver como isso pode funcionar.

No exemplo abaixo, estou escrevendo testes em um plugin que é responsável por se comunicar com uma API de terceiros. Este plugin em particular requer um nome de usuário e senha ou uma API e queremos ter certeza de que, para os propósitos deste post, ele está recuperando corretamente um erro sempre que o teste for executado.

Observe que ao ler este código, você me verá falar um pouco sobre reflexão. Eu vou fazer um post inteiro sobre PHP Reflection em breve, então ele vai esclarecer um pouco sobre isso.

No entanto, para o código abaixo, suponha que seja uma maneira de obter acesso a propriedades marcadas como privadas.

Lembre-se do último post desta série, tivemos um teste inicial que se parecia com isso:

Observe, no entanto, que neste teste não há função tearDown que faça sentido, certo? Afinal, nada está sendo gravado em um banco de dados ou em um arquivo.

Mas digamos que queremos apresentar um caso de teste que terá um nome de arquivo, conteúdo e gravará o conteúdo no arquivo. Nesse caso, serão dados estáticos, mas tecnicamente podem ser qualquer coisa gravada em disco.

1 Configurando o Teste

Primeiro, queremos configurar o teste definindo o nome do arquivo, o conteúdo do arquivo e preparando as propriedades.

Fácil o suficiente, certo?

2 Gravar e Ler Dados

Em seguida, queremos escrever os dados, ler os dados e afirmar que o conteúdo é o mesmo.

Neste ponto, se você executar o teste (que ainda não abordei tecnicamente sobre como fazer), você notará que testFile.txt ainda reside em seu sistema.

3 Usando desmontagem

Por fim, precisamos trabalhar com o método tearDown para garantir que o arquivo seja excluído após a conclusão do teste de unidade. Veja como pode ficar se você implementou seu código como o que você vê acima.

Observe que no método tearDown, primeiro verifico se um file_exists. Isso ocorre porque se você simplesmente tentar desvincular um arquivo que não está presente, receberá um erro ao executar seus testes porque, se o tearDown estiver presente, ele tentará excluir algo após cada função de teste. E se o arquivo não existir, então não há nada para deletar e, portanto, resultará em um problema.

Portanto, na tentativa de escrever código defensivamente, acredito que seja responsável por verificar se o arquivo existe antes de tentar excluí-lo.

3 Ordem de Operações

Quando se trata de testes unitários puros, você normalmente lerá isso em termos de desenvolvimento orientado a testes. Este é um grande tópico em si; no entanto, vale a pena mencionar aqui se você optar por pesquisá-lo mais e até mesmo implementá-lo em seus esforços de desenvolvimento.

A ideia geral por trás dessa abordagem é frequentemente chamada de “repetição vermelha-verde”. E não estou negando, há algo nessa abordagem. Ou seja, ele permite que você, como desenvolvedor, escreva o código como você espera que funcione antes de realmente escrever o código.

A psicologia por trás disso é esta: se você sabe como o código funciona, é mais provável que você escreva testes que passem; ao passo que, se você escrever testes de como o código deve ser executado, deverá escrever um código melhor.

Infelizmente, nem sempre temos esse luxo. Mas isso não significa que devemos jogar fora o proverbial bebê junto com a água. Em vez disso, sou da opinião de que você deve escrever testes quando puder e escrever o código depois; caso contrário, escreva seus testes após seu código.

Em última análise, ter testes em vigor, independentemente, será melhor do que nenhum teste.

4 Testando com WordPress

Quando se trata de teste de unidade no WordPress, há algumas coisas que você provavelmente já encontrou. Às vezes, o conteúdo é um nome impróprio ou pode até ser enganoso em termos de “teste de unidade no WordPress”.

Caso em questão, há duas coisas dignas de nota:

1. O Teste de Unidade de Tema. Esse conjunto específico de conteúdo destina-se a ajudar os desenvolvedores de temas a testar todos os casos principais e secundários de seus temas. Não há ferramentas automatizadas, por exemplo, que você usaria como no que discutimos acima.
2. Testes Automatizados. O WordPress vem com seu próprio conjunto de testes de unidade para que não tenhamos que escrever testes contra a maioria das funcionalidades do WordPress (como se as funções da API funcionam ou não conforme o esperado). Isso nos permite focar em escrever testes de unidade para nossa própria lógica de domínio.
3. Testes de unidade de plug-in. Se você usou o WP-CLI (ou está interessado nele), provavelmente leu esta página ou até mesmo usou essas ferramentas. É útil, mas também visa aspectos específicos do teste de plugins do WordPress.

Todos os itens acima são informações úteis e não estou dizendo que devam ser ignorados. Em vez disso, deve ser combinado com o restante das informações usadas ao longo deste post.

Executando testes de unidade

No próximo post, mostrarei tudo o que você precisa saber para configurar um arquivo XML que informará ao PHPUnit onde os testes residem e como executá-los.

Por enquanto, porém, revise o código que está neste post e prepare-se para construí-lo no próximo post desta série.