Todos podemos concordar que o WordPress percorreu um longo caminho desde o seu início e que se transformou em algo muito mais do que um software de blog.
Em sua essência, ainda é um sistema de gerenciamento de conteúdo (CMS), mas com mais de 59.000 plugins no diretório wordpress.org, você pode personalizá-lo para ser muito mais.
A razão de sua popularidade é sua baixa barreira de entrada para criadores e desenvolvedores de conteúdo. Às vezes isso vem com um custo. Não é nenhum segredo que o WordPress tem uma má reputação quando se trata de desenvolvimento. Ele tem muita bagagem herdada e regras obstinadas que impedem qualquer alteração de quebra de compatibilidade com versões anteriores quando se trata de código PHP (Gutenberg é outra história na qual não entrarei).
Esse código PHP legado é frequentemente usado pelos desenvolvedores que estão começando a entrar no mundo da programação, e o problema é que eles podem aprender alguns padrões de programação ruins. Isso, por sua vez, significa que eles reutilizarão o código mal escrito, aumentando a quantidade de código ruim no mundo.
É aqui que o WordPress obtém sua má reputação na comunidade de desenvolvedores.
Quebrando o ciclo
Então, como podemos quebrar esse ciclo de código ruim? Ensinando novos desenvolvedores como eles devem escrever um bom código. Um exemplo de ensinar os novos desenvolvedores (mas também os antigos que ainda estão apegados à maneira ‘WordPress’ de fazer as coisas) é escrever tutoriais.
Outra maneira é incentivá-los a usar ferramentas que possam ajudá-los a escrever um código melhor.
Atualmente estou envolvido no trabalho que visa lançar a nova versão do WordPress Coding Standards, um conjunto de regras usadas para a ferramenta PHP_CodeSniffer que permitirá que você saiba se seu código possui alguns problemas potenciais (segurança, melhores práticas, estilo de código ).
Outra ferramenta que desenvolvi recentemente é um pacote que ajudará os desenvolvedores a configurar os testes de integração do WordPress que usam o framework de testes Pest.
Ok, então por que precisamos dessa nova ferramenta?
A principal motivação por trás da criação deste pacote é encorajar mais pessoas a escreverem testes para seus códigos, especialmente desenvolvedores de plugins.
Muitos desenvolvedores na comunidade WordPress seguem o mantra: posso ver que funciona porque experimentei no meu navegador. Tudo bem, mas há problemas com isso.
Primeiro, é demorado. Toda vez que você fizer alguma mudança, você precisa ter certeza de que funciona, mas também que você não quebrou nada.
Em segundo lugar, as pessoas cometem erros. Não somos infalíveis, e o código pode ser mal utilizado de maneiras que você nunca imaginou ser possível. Você ficaria surpreso com o quão criativas as pessoas podem ser ao escrever código.
Testes automatizados são rápidos e podem te ajudar a testar diversos casos que vão acontecer quando você executar seu código.
Você testa o comportamento pretendido (caminho feliz) e, de maneira rápida, pode adicionar exemplos de como seu código pode ser usado de uma maneira que você não pretendia que fosse usado (caminho infeliz).
Ele também protege seu código de regressões. Uma regressão de código é quando você involuntariamente quebra uma parte do seu código adicionando um novo código.
O problema com os testes configurados até agora
Testar no WordPress não é uma coisa nova. E não é como se você não pudesse configurar testes para seu código antes. Existem bibliotecas incríveis por aí que ajudarão você a configurar tudo como o wp-browser.
Mas o problema é que o procedimento de configuração é muitas vezes desajeitado.
Você precisa configurar um banco de dados separado para testes e precisa executar determinados scripts e, em seguida, alterar os arquivos para que tudo funcione.
Vamos encarar, não é uma coisa simples de fazer, e os desenvolvedores são criaturas preguiçosas por natureza (é por isso que escrevemos código para fazer as coisas por nós 😄).
O objetivo da configuração do teste de integração wp-pest é eliminar todo esse trabalho extra.
Como configurá-lo
Para configurá-lo, seu projeto deve usar o Composer. É uma maneira padrão de fato de adicionar pacotes ao seu código.
No seu tipo de terminal
composer require dingo-d/wp-pest-integration-test-setup --devDepois de baixar o pacote e suas dependências, você pode configurar os testes do tema digitando
vendor/bin/wp-pest setup themeOu, no caso de você querer configurar testes para seu plugin, você pode escrever
vendor/bin/wp-pest setup plugin --plugin-slug=your-plugin-slugOpcionalmente, você pode fornecer um --wp-version parâmetro, para especificar em qual versão do WordPress você gostaria de testar seu código.
Em segundo plano, uma instância do WordPress será baixada e um banco de dados na memória será configurado, juntamente com dois exemplos de testes que você pode executar.
Então, executando ou
vendor/bin/pest --group=unitou
vendor/bin/pest --group=integrationfará os testes.
A beleza do Pest é que sua sintaxe é amigável ao desenvolvedor. Possui documentação incrível e ótima sintaxe. Vejamos um exemplo simples. Digamos que você esteja registrando um tipo de postagem personalizado chamado ‘Livros’:
esc_html__( 'Books', 'test-plugin' ),
'public' => true,
'publicly_queryable' => true,
'show_ui' => true,
'show_in_menu' => true,
'query_var' => true,
'rewrite' => array( 'slug' => 'book' ),
'capability_type' => 'post',
'has_archive' => true,
'hierarchical' => false,
'menu_position' => null,
'supports' => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' ),
);
register_post_type( 'book', $args );
}
add_action( 'init', 'test_plugin_register_books_cpt' );
Após executar o comando setup que adiciona um exemplo, um teste chamado BooksCptTest.php ficaria assim:
assertNotFalse(has_action('init', 'test_plugin_register_books_cpt'));
$registeredPostTypes = get_post_types();
// Or we can use expectations API from Pest.
expect($registeredPostTypes)
->toBeArray()
->toHaveKey('book');
});
Encontro vendor/bin/pest --group=integration nos dá a seguinte saída:
Installing...
Running as single site... To run multisite, use -c tests/phpunit/multisite.xml
Not running ajax tests. To execute these, use --group ajax.
Not running ms-files tests. To execute these, use --group ms-files.
Not running external-http tests. To execute these, use --group external-http.
PASS Tests\Integration\BooksCptTest
✓ Books custom post type is registered
Tests: 1 passed
Time: 0.14sConclusão
E assim, você tem a capacidade de executar testes de integração do WordPress em seu tema ou plugin. Os testes são incríveis porque não apenas nos protegem de erros, mas também nos forçam a escrever um código limpo e testável. Isso é especialmente verdadeiro para plugins que possuem lógica complicada ou estão se comunicando com APIs de terceiros.
Escrever testes para tal base de código irá forçá-lo a pensar sobre a aparência de sua arquitetura de código para que você possa facilmente escrever testes automatizados – sem mencionar o tempo e dinheiro que você economizará por não ter que testar tudo manualmente.
Se você acha que isso é algo que você pode se beneficiar, sinta-se à vontade para usá-lo e estrelar o repositório no GitHub.
Espero que isso incentive mais desenvolvedores do WordPress a usar ferramentas que aprimorem suas habilidades de codificação.
