Escrevendo testes de unidade com PHPUnit, parte 1: a configuração

No início deste mês, começamos a analisar a instalação do PHPUnit no Visual Studio Code com o objetivo final de aprender a escrever testes de unidade para nossos projetos baseados em WordPress.

Para esse fim, este post pressupõe que você leu os seguintes posts e assume que você alcançou um punhado de posts anteriores:

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

E, claro, instalando o PHPUnit no Visual Studio Code conforme link acima. Feito isso, estaremos prontos para prosseguir. Mas uma coisa a ter em mente é que esta noite será um curso tradicional ou abrangente sobre como escrever testes unitários.

Em vez disso, trata-se de escrever testes de unidade para projetos do WordPress.

Testes de unidade com PHPUnit, Parte 1: A configuração

Antes de me aprofundar muito nisso, quero deixar claro que este não é tanto um post sobre desenvolvimento orientado a testes, mas um post que estabelece as bases para entender a escrita de testes de unidade. E então, finalmente, trabalharemos para escrever testes de unidade para nosso código.

Para aqueles de vocês que fizeram alguma leitura prévia sobre testes de unidade, então você sabe que escrever testes de unidade é um tópico para o qual há muitas informações e este post não tentará cobrir tudo isso. Em vez disso, será necessária uma abordagem mais pragmática para escrever testes de unidade em plugins baseados em WordPress, aplicativos da web e similares.

1 Escrevendo Testes Unitários

Sempre que você começar a escrever testes de unidade, você verá a ideia dos métodos setUp e tearDown. Isso é comum no PHPUnit (assim como em outros frameworks de teste). Existem algumas coisas sobre esses dois métodos específicos que geralmente causam problemas.

Resumindo, as pessoas tratam as funções assim:

• setUp é como o construtor no qual você instancia sua classe e então prepara tudo o que precisa para o teste, incluindo o objeto a ser testado, os dados necessários e assim por diante.
• tearDown é o destruidor onde você redefine tudo e depois descarta seus objetos. Isso geralmente é mais comum em linguagens compiladas, mas também não deve ser esquecido no PHPUnit.

E embora eu possa entender isso completamente, nem sempre é o caso. Estou falando por experiência aqui também. Em vez disso, é de onde vem o teste de unidade de frase real. Trata-se de testar o código do código das unidades e fazê-lo de maneira limpa e concisa.

Então, para que servem esses métodos, afinal? Isso pode ser um hábito especialmente difícil de quebrar ou até mesmo um modelo conceitual de quebrar quando você está entrando no processo pela primeira vez. Para esse fim, quero examinar o propósito de cada método e como abordar isso ao trabalhar com projetos baseados em WordPress.

E, como sempre, tentarei manter isso o mais simples e pragmático possível. Estou muito menos interessado na teoria por trás de certas coisas do que em como ela pode servir tanto ao meu negócio quanto aos meus projetos. (Isso não é para desconsiderar a teoria, é claro, mas há um tempo não é um lugar para isso e este blog não é isso.)

2 A função de configuração

Embora eu esteja começando com uma breve discussão sobre o método setUp, é importante ter em mente que sua função irmã (como alguns consideram) nem sempre é necessária.

Por exemplo, se você estiver escrevendo código em que tudo o que está fazendo é instanciar um objeto ou um conjunto de objetos, o método tearDown pode não ser necessário. Entrarei em mais detalhes sobre isso na próxima seção.

Com isso dito, digamos que você tenha uma classe responsável por executar um pouco de lógica de domínio. Lembre-se, para os propósitos deste post, não estamos preocupados com código que fará coisas que o WordPress faz naturalmente e que já possui seu próprio conjunto de testes.

Com isso, quero dizer que estamos preocupados com o código que funciona especificamente dentro de um domínio de problema. Por exemplo, talvez estejamos preocupados em escrever uma classe que armazena dados em cache no banco de dados. Uma das informações responsáveis ​​por armazenar em cache as informações é por quanto tempo os dados devem ser armazenados em cache. Assim, um candidato para o teste unitário faria o uso que podemos definir e alterar a quantidade de tempo, certo?

Concedido, talvez esses dados sejam codificados, mas para fins de exemplo, vamos supor o contrário. Isso implica o seguinte:

• Temos uma classe que serve como nosso cache,
• A classe mantém uma parte dos dados da instância por quanto tempo o cache deve ser definido,
• O tempo de cache pode ser definido a partir de classes de terceiros,
• O tempo de cache pode ser lido de classes de terceiros.

Isso significa que um teste de unidade incluiria:

1. Configurando a aula,
2. Definindo um valor,
3. Afirmando que o valor que foi definido é o esperado,,
4. Mudando o valor,
5. A declaração do valor que foi alterado foi atualizada.

Portanto, a classe básica pode ser algo assim (toda a documentação sendo deixada de fora da classe para manter o código o mais conciso possível):

Observe que, por padrão, temos o tempo de cache definido em 12 horas (em segundos). A classe suporta a capacidade de alterar e ler a duração também.

Isso significa que podemos escrever testes que testam:

• se o valor inicial for o esperado,
• se o novo valor for o esperado (e sobrescrever o valor inicial)

Uma das coisas que eu gostaria de salientar no código acima é que você pode ler que cada teste deve ter uma única asserção enquanto testNewDuration claramente tem duas asserções.

Costumo tomar a ideia de uma afirmação por teste como regra geral. Por exemplo, neste caso, quero afirmar que o valor inicial é substituído ou não armazenado em nenhum lugar e o novo valor é armazenado.

Isso pode nem sempre ser o caso, então você pode precisar tratar esses tipos de situação com cuidado.

Como você pode ver, isso não tem nada a ver com o WordPress; no entanto, tem a ver com a lógica de teste relacionada especificamente ao domínio em questão. Ou seja, a duração do cache. E é disso que se trata o núcleo do teste de unidade: Testar o comportamento lógico das unidades de código para garantir que as coisas funcionem conforme o esperado.

E dependendo de quando você escreve esse código, você pode ter testes com falha. Isso pode ajudar no design da classe, mas esse é outro tópico e não faz parte deste post.

Executando os testes

Uma vez que os testes são escritos, é importante poder executá-los para ver se eles passam, se falham, o que passa e o que não. Mas ainda não terminamos. Eu quero fornecer uma visão abrangente dos testes de unidade no contexto do WordPress e discutir o que o WordPress fornece, o que não oferece, alguns equívocos e como executar esses testes no terminal ou no Visual Studio Code.

No próximo post desta série, veremos a função tearDown e como (e quando) usá-la, quando é necessário, quando não é, e então vamos dar uma olhada em torno da unidade testes no WordPress em geral.

Em última análise, estamos trabalhando para obter uma visão completa de como fazer isso e como fazê-lo corretamente. Mas é importante estabelecer as bases para isso e fazê-lo ao longo de alguns postes é mais fácil do que em um post monolítico.

Portanto, examinar tearDown(), seu uso e como executar testes a partir da linha de comando será o tópico do próximo post desta série.