Introdução

Tem sido difícil e doloroso, mas tenho boas razões para escrever drupal orientado a testes. Por anos eu venho dizendo que o teste é superior a tipos fortes (o mesmo argumento que eles usam para promover a escrita, deve ser usado para promover TDD em vez disso, e testar é uma mentalidade muito superior). Para ser fiel à minha palavra, eu emprego desenvolvimento baseado em testes (TDD) em cada pilha: ruby, javascript front-end, php e finalmente python. Embora um pouco difícil, desenvolvedores Drupal têm escrito testes por um tempo, e usam testes avançados de integração. Neste artigo, vou falar sobre configurar o ambiente de teste e executar um único teste do kernel.

Recentemente atualizei de Drupal 9 para Drupal 10 e tive que mudar versões de tudo. Geralmente não recomendo: recomendo ficar confortavelmente na versão antiga. Drupal 10 é mais gordo e mais lento do que Drupal 9, e eu realmente *perdeu * funcionalidade após a atualização, e não ganhou nenhuma nova funcionalidade. Portanto, eu parei a migração do meu ecossistema e vou manter os sites drupal não migrados na versão 9, enquanto eu posso. Eu vou manter o drupal 10 sites também sem reverter - porque reverter iria exigir que eu faça trabalho para ir para trás - algo que eu não posso recomendar.

Acho que a principal motivação e palavras de encorajamento que tenho para desenvolvedores drupais iniciantes/intermediários que estão procurando incorporar testes é, que funciona. Se você se sentir frustrado com todas as partes móveis e um pouco contra-intuitiva configuração, eu quero dizer, ter fé que você pode fazê-lo funcionar, problemas podem ser resolvidos, e ele começa a funcionar depois de um tempo.

E agora a parte técnica.

Resolução de Dependências

Fiquei preso com vários erros de versão! O erro que imprime é algum erro obscuro, insondável, e para corrigi-lo eu tive que version-match múltiplos pacotes. Você *tem que* especificar versões, parece que o compositor não fará um bom trabalho para você. A árvore de dependência não é óbvia: versão 10.6 *requer* versão 7.4 em outro lugar. Eu não sei suas versões exatas, e você pode pedir GPT ou de outra forma certifique-se de suas versões estão certas. Eu também tive que downgrade dois módulos não relacionados: "symfony/css-selector": "^6.4" e "symfony/dom-crawler": "^6.4".

composer require --dev drupal/core-dev:10.6.12 -W
composer require --dev symfony/phpunit-bridge:^7.3 ## drupal 10.6
composer require --dev phpunit/phpunit
composer require --dev behat/mink

Eventualmente, as minhas versões funcionaram.

Então eu pedi GPT para escrever um teste mínimo. Vamos usar esse em vez dos meus testes.

<?php
// file $MODULE_ROOT/tests/src/Kernel/SanityTest.php
namespace Drupal\Tests\ish_drupal_module\Kernel;
use Drupal\KernelTests\KernelTestBase;
class SanityTest extends KernelTestBase {
 protected static $modules = [ 'system' ];
 public function testTrue(): void {
   $this->assertTrue(TRUE);
 }
}

E agora vamos tentar fazer este teste.

Ligando o aplicativo de testes

Agora, uma questão interessante e importante é como configurar o ambiente de teste para o módulo. Implemento o módulo com compositor dentro do docker, então a implantação da produção inclui (1) bater a versão no composer.json e (2) executar `composer require wasya-co/ish drupal module`. Este obviamente não é um ambiente de teste, e por isso um bom arnês de teste tem de ser adicionado. Decidi adaptar uma estratégia do ecossistema ruby-on-rails. Eu empacoto um aplicativo drupal mínimo, via docker, dentro do módulo - mesmo que o módulo seja esperado para viver dentro de algum outro ambiente de produção. Desta forma, o módulo carrega seu próprio aplicativo, apenas para testes, o que o torna auto-suficiente para testes, e não depende de outro projeto.

Você pode ver a fiação real do meu módulo porque é de código aberto: https://github.com/wasya-co/ish drupal module

Eu copiei o arquivo docker-compose.yml da produção. A mudança importante é não usar volumes, e usar volumes de ligação.

Não precisa ser um aplicativo funcional, já que só o uso para testes. Se você gostaria que eu fizesse dele um aplicativo funcional, por favor, deixe-me uma mensagem.

Depois de iniciar o recipiente, posso fazer login:

./scripts/login test

E fazer um teste no recipiente:

composer install
export SIMPLETEST_DB="mysql://root:test1234@mysql/ish_drupal_module_test"
export SIMPLETEST_BASE_URL="http://127.0.0.1"
./vendor/bin/phpunit \
 -c /var/www/html/web/core/phpunit.xml.dist \
 web/modules/custom/ish_drupal_module/tests/src/Kernel/SanityTest.php

Novamente, observe que o teste está encapsulado dentro do módulo, como deveria ser. Nenhum código externo é necessário para executá-lo.

E voilá! Estamos no negócio.