Compreendendo o jargão de testes unitários do WordPress

Em nosso último post, demos uma olhada básica em como testar seu código no WordPress. Hoje, daremos mais um passo em direção à escrita de código bem testado, apresentando (e ajudando você a entender) todo o jargão que aparece quando você fala sobre testes unitários para WordPress.

Tipos de testes

Sim, testes unitários não são os únicos tipos de testes que podemos ter para nossa aplicação, então vamos dar uma olhada nos diferentes tipos de testes que você pode usar em seu trabalho.

Testes unitários

Esses tipos de testes são o primeiro estágio de um sistema de testes. Eles testam especificamente para garantir que o código que você escreveu tenha o desempenho esperado. Os testes unitários formam a base dos seus testes porque se o seu código não funcionar corretamente, os tipos posteriores de testes serão construídos sobre uma base instável.

Se eu quisesse limitar a edição de links permanentes aos administradores do site para postagens com mais de duas semanas, meu teste de unidade usaria WP_Mock para garantir que tenho um usuário do tipo adequado e uma postagem com a data adequada. Então eu me certificaria de que minha função retornasse o valor verdadeiro ou falso esperado.

Os testes unitários não devem ter dependências fora do código que você escreveu. Eles não devem interagir com nenhum outro sistema. Isso significa que nosso último post não foi um verdadeiro teste de unidade, foi um teste de integração porque interagimos com o banco de dados conforme criamos nosso usuário.

Ao usar testes de unidade como base do seu trabalho, você ajuda a garantir que cada método/função tenha uma única responsabilidade, pois fica cada vez mais difícil testar à medida que você adiciona mais condições a uma única função.

Algumas das ferramentas que você encontrará em projetos WordPress de teste de unidade são:

Testes de Integração

Este é o segundo tipo de teste que você fará em seu trabalho. Os testes de integração garantem que as interações entre dois sistemas funcionem conforme o esperado. Ao contrário dos testes unitários, o objetivo aqui é ver a interação entre vários sistemas.

Ler:  Como adicionar um livro de visitas gratuito a um site WordPress

O próprio WordPress faz mais testes de integração do que testes de unidade porque quando a maior parte do aplicativo foi escrita, as práticas recomendadas eram diferentes. As funções dentro do WordPress são muito maiores do que muitos CMS PHP mais recentes e realizam muito mais trabalho. Essas funções maiores são difíceis de testar adequadamente porque fazem muito. Isso significa que confiamos mais em testes de integração à medida que verificamos como nosso código funciona diretamente com o WordPress.

Nada disso é ruim, é simplesmente o produto de um aplicativo que não foi criado quando os testes eram tão comuns como são agora.

Outro exemplo de teste de integração seria se você estivesse construindo uma integração com uma plataforma de email marketing. Você pode usar testes de unidade para validar o e-mail corretamente e enviar o formulário conforme esperado. Testes de integração seriam usados ​​para garantir que, ao enviar seu e-mail válido para a plataforma de e-mail, você lide com a resposta de maneira adequada.

Ferramentas para testes de integração:

Teste de mutação

O teste de mutação só será usado para projetos que já possuem algum tipo de cobertura de teste. Esse tipo de teste cria “mutantes” em seu código, introduzindo erros comuns de codificação. O objetivo é que seus testes de unidade sejam interrompidos quando esses erros forem introduzidos, o que significa que você capturou e matou o mutante. As ferramentas de teste de mutação informarão quantos mutantes você matou e os locais onde você não capturou mutantes.

O teste de mutação pode ser usado para medir a qualidade da cobertura do seu teste. Se você tem muitos mutantes junto com 100% de cobertura de testes, você tem um grande problema. Isso significa que seus testes não detectam erros comuns cometidos pelos programadores. Você tem uma quebra de código esperando para acontecer.

Essencialmente, você está testando seus testes.

Ferramentas para testes de mutação:

Testes de aptidão

Eles também podem ser chamados de teste funcional ou teste de navegador. Enquanto os testes de unidade começam com o seu código e seguem em frente, os testes de aceitação consideram a visão da pessoa que usa o seu software. Com os testes de aceitação, você pode automatizar o navegador da web para interagir com seu site e garantir que os usuários vejam o que esperam ver.

Ler:  Como adicionar ícones de mídia social ao WordPress com imagem de menu

Os testes de aceitação são mais difíceis de manter porque uma pequena alteração no texto da IU do seu software pode significar que o teste será interrompido porque a automação não consegue mais encontrar os elementos da IU que espera encontrar. Por esse motivo, invista apenas em testes de aceitação de infraestrutura crítica para o negócio, como o processo de checkout no carrinho de compras.

Ferramentas para testes de aceitação:

Jargão

Agora que cobrimos os tipos de testes que você pode fazer, precisamos ter certeza de que entendemos a outra linguagem que os desenvolvedores usarão ao escrever os testes.

Duplas de teste

O termo teste duplo é um termo genérico que se refere a qualquer momento em que você substitui um objeto/função/coisa de produção para fins de teste. Fizemos isso em nosso post anterior sobre Primeiros passos com testes unitários no WordPress, quando usamos WP_UnitTestCase para adicionar um usuário que não existia em nosso banco de dados de produção. Pode ser útil pensar nisso como um dublê que “substitui” o ator quando as coisas ficam perigosas. O teste duplica o “substituto” de nossos dados e código para facilitar o teste. Eles devem ter a aparência e o comportamento de seus equivalentes de produção, mas ser simplificados para reduzir a complexidade durante os testes.

Zombar

Mocks são usados ​​quando você não deseja interagir com a API ou banco de dados. Você usa uma simulação para falsificar interações com o banco de dados para poder testar uma única unidade de código sem adicionar a complexidade de um banco de dados.

Uma simulação não precisa ser dados em um banco de dados. Uma ferramenta como WP_Mock tem a capacidade de falsificar o sistema de ganchos dentro do WordPress. Isso permite testar se um gancho foi chamado em sua função, sem a necessidade de interagir com o próprio WordPress.

Abaixo podemos ver um exemplo em WP_Mock onde falsificamos a função get_permalink. Fornecemos o número de vezes que esperamos que a função seja chamada, os argumentos que esperamos e o valor que esperamos retornar.

Ler:  Como exibir um mapa vetorial responsivo no WordPress

\WPMock::userFunction( ‘getpermalink’, array(

‘argumentos’ => 42,

‘vezes’ => 1,

‘return’ => ‘https://theanswertoeverything.fourtytwo/guide

Abordaremos como usar WP_Mock em uma postagem futura.

Esboços

Stubs são valores codificados para nossos testes, como respostas prontas para as perguntas que nosso teste pode fazer. Você usaria um stub se instruísse seu teste a assumir que um usuário está logado durante a execução de um teste. Outro teste pode assumir que o usuário está desconectado. Ambos os testes garantiriam que suas funções retornassem os valores adequados para a ramificação fornecida em seu código.

É muito provável que você esteja usando stubs e mocks juntos. No exemplo acima, você usa um stub para assumir o valor logado e, em seguida, uma simulação para garantir que os valores adequados sejam retornados.

Bobos

Os manequins de teste são usados ​​quando você não se importa com o que o código faz. Talvez você use um manequim para preencher um array ou lista de parâmetros para que o código funcione corretamente. Stubs são informações extras que provavelmente não importam no contexto do teste específico que você está escrevendo.

Para um usuário logado, talvez parte da função do seu teste espere um nome. Mesmo que seu teste atual não precise desse nome, você precisa garantir que ele esteja preenchido para que seu teste seja aprovado. Claro, você também deve testar o resultado da sua função sem esse nome para ter certeza de que lidará com as condições de falha corretamente.

Fábricas

Uma fábrica é uma ferramenta que nos permite preencher objetos válidos em nosso modelo de dados para que possamos testar os dados. Em nosso último caso usamos uma fábrica quando adicionamos um usuário ao nosso código dentro de WP_UnitTestCase.

Uma coisa a ter cuidado aqui é alterar o modelo de dados em seu código. Se o seu usuário precisar repentinamente de um campo extra, você precisará realizar todos os testes e certificar-se de ter adicionado esse campo extra sempre que usar uma fábrica.

Macaco Patch

Este é um termo genérico para substituir atributos e funções dinamicamente em tempo de execução. WP_Mock é um “monkey patching”, substituindo as funções padrão do WordPress para teste. Isso significa que não precisamos acessar o WordPress diretamente quando estivermos testando a unidade.

Ler:  Implante WordPress com ações do Github

Asserções

Uma afirmação é um valor booleano que será verdadeiro a menos que haja um erro. Um exemplo seria usar assertFileEquals para verificar se um arquivo possui o conteúdo esperado. Ele retornará verdadeiro se o arquivo corresponder às expectativas e você passar no teste.

BDD ou TDD?

Agora, com qual sistema geral você abordará seus testes? Importa mais que as funções individuais sejam válidas ou que o comportamento que o usuário final vê seja válido?

TDD

TDD ou Test Driven Development é quando você escreve testes para validar se o código funciona conforme o esperado. Assim como os testes de unidade, você começa com a expectativa do código e depois trabalha em direção ao cliente/usuário à medida que avança. O TDD não se preocupa com as saídas, apenas se preocupa com que os testes funcionem conforme o esperado.

Os testes escritos sob TDD só serão legíveis por desenvolvedores que entendem de testes e o que significa uma afirmação.

BDD

BDD ou Behavior Driven Development surgiu das deficiências do TDD. Aqui você começa com o que o usuário final espera que aconteça como resultado do código. Você ainda escreve seus testes primeiro, mas os concentra no resultado do seu código. O BDD não se importa como você chega aos resultados, desde que o comportamento esperado seja o resultado.

Um grande benefício para ferramentas BDD como Pepino é que a linguagem usada para escrever o teste seja facilmente legível por clientes e desenvolvedores. É fácil entender que os clientes podem escrever solicitações de recursos usando o Cucumber após uma breve introdução.

Agora, qual você deve usar? A resposta correta é provavelmente um pouco das duas. Os métodos TDD podem ser usados ​​para garantir que o código que o desenvolvedor escreve seja executado conforme o esperado. O BDD pode ser usado para garantir que a saída desse código seja o que o cliente espera que aconteça.

Isso é tudo, pessoal! Compreender os testes unitários do WordPress ficou muito mais fácil. Com todo esse jargão em mãos, você estará pronto para o próximo post onde construiremos um plugin usando TDD e BDD com todas as ferramentas à nossa disposição.

Novas publicações:

Recomendação