Estrutura de teste WP-CLI
Links rápidos: Usando | Contribuindo | Apoiar
Para usar a estrutura de teste WP-CLI, você precisa concluir as seguintes etapas no pacote ao qual deseja adicioná-los:
Adicione a estrutura de teste como um requisito de desenvolvimento:
composer require --dev wp-cli/wp-cli-tests
Adicione os scripts de teste necessários ao arquivo composer.json
:
"scripts" : {
"behat" : " run-behat-tests " ,
"behat-rerun" : " rerun-behat-tests " ,
"lint" : " run-linter-tests " ,
"phpcs" : " run-phpcs-tests " ,
"phpcbf" : " run-phpcbf-cleanup " ,
"phpunit" : " run-php-unit-tests " ,
"prepare-tests" : " install-package-tests " ,
"test" : [
" @lint " ,
" @phpcs " ,
" @phpunit " ,
" @behat "
]
}
É claro que você pode remover aqueles de que não precisa.
Opcionalmente, adicione um tempo limite de processo modificado ao arquivo composer.json
para garantir que os scripts possam ser executados até que seu trabalho seja concluído:
"config" : {
"process-timeout" : 1800
},
O tempo limite é expresso em segundos.
Opcionalmente, adicione um arquivo behat.yml
à raiz do pacote com o seguinte conteúdo:
default :
suites :
default :
contexts :
- WP_CLITestsContextFeatureContext
paths :
- features
Isso garantirá que o sistema automatizado do Behat funcione em todas as plataformas. Isso é necessário no Windows.
Opcionalmente, adicione um arquivo phpcs.xml.dist
à raiz do pacote para ativar o estilo de código e verificações de práticas recomendadas usando PHP_CodeSniffer.
Exemplo de um conjunto de regras personalizado mínimo baseado nos padrões definidos na estrutura de testes WP-CLI:
<? xml version = " 1.0 " ?>
< ruleset name = " WP-CLI-PROJECT-NAME " >
< description >Custom ruleset for WP-CLI PROJECT NAME</ description >
<!-- What to scan. -->
< file >.</ file >
<!-- Show progress. -->
< arg value = " p " />
<!-- Strip the filepaths down to the relevant bit. -->
< arg name = " basepath " value = " ./ " />
<!-- Check up to 8 files simultaneously. -->
< arg name = " parallel " value = " 8 " />
<!-- For help understanding the `testVersion` configuration setting:
https://github.com/PHPCompatibility/PHPCompatibility#sniffing-your-code-for-compatibility-with-specific-php-versions -->
< config name = " testVersion " value = " 5.4- " />
<!-- Rules: Include the base ruleset for WP-CLI projects. -->
< rule ref = " WP_CLI_CS " />
</ ruleset >
Todas as outras opções de configuração do PHPCS estão, obviamente, disponíveis.
Atualize suas dependências do compositor e gere novamente seu autoloader e pastas binárias:
composer update
Agora você está pronto para usar a estrutura de teste do seu pacote.
Você pode usar os seguintes comandos para controlar os testes:
composer prepare-tests
- Configure o banco de dados necessário para executar os testes funcionais. Isso só é necessário uma vez.composer test
- Execute todos os conjuntos de testes.composer lint
- Execute apenas o conjunto de testes linting.composer phpcs
- Execute apenas o conjunto de testes do sniffer de código.composer phpcbf
- Execute apenas a limpeza do sniffer de código.composer phpunit
- Execute apenas o conjunto de testes unitários.composer behat
- Execute apenas o conjunto de testes funcionais.Para enviar um ou mais argumentos para uma das ferramentas de teste, coloque um travessão duplo antes do(s) argumento(s). Como exemplo, veja como executar testes funcionais apenas para um arquivo de recurso específico:
composer behat -- features/cli-info.feature
Anexar o traço duplo é necessário porque, caso contrário, os argumentos seriam enviados para o próprio Composer, não para a ferramenta que o Composer executa.
Você pode executar os testes em uma versão específica do WordPress definindo a variável de ambiente WP_VERSION
.
Esta variável compreende qualquer versão numérica, bem como os termos especiais latest
e trunk
.
Nota: Isto se aplica apenas aos testes funcionais do Behat. Todos os outros testes nunca carregam o WordPress.
Veja como executar seus testes na versão tronco mais recente do WordPress:
WP_VERSION=trunk composer behat
Você pode executar os testes em um binário WP-CLI específico, em vez de usar aquele que foi criado na pasta vendor/bin
do seu projeto.
Isso pode ser útil para executar seus testes em uma versão Phar específica do WP_CLI.
Para fazer isso, você pode definir a variável de ambiente WP_CLI_BIN_DIR
para apontar para uma pasta que contém um binário wp
executável. Nota: o binário deve ser nomeado wp
para ser reconhecido corretamente.
Por exemplo, veja como executar seus testes em uma versão específica do Phar que você baixou.
# Prepare the binary you've downloaded into the ~/wp-cli folder first.
mv ~ /wp-cli/wp-cli-1.2.0.phar ~ /wp-cli/wp
chmod +x ~ /wp-cli/wp
WP_CLI_BIN_DIR= ~ /wp-cli composer behat
Regras básicas para configurar a estrutura de teste com Travis CI:
composer prepare-tests
precisa ser chamado uma vez por ambiente.linting and sniffing
são análises estáticas, portanto não devem depender de nenhum ambiente específico. Você deve fazer isso apenas uma vez, como um estágio separado, em vez de por ambiente.composer behat || composer behat-rerun
faz com que os testes do Behat sejam executados em sua totalidade primeiro e, caso seus cenários tenham falhado, uma segunda execução é feita apenas com os cenários com falha. Isso geralmente evita problemas intermitentes, como tempos limite ou similares.Aqui está uma configuração básica de como você pode configurar o Travis CI para funcionar com a estrutura de teste (extrato):
install :
- composer install
- composer prepare-tests
script :
- composer phpunit
- composer behat || composer behat-rerun
jobs :
include :
- stage : sniff
script :
- composer lint
- composer phpcs
env : BUILD=sniff
- stage : test
php : 7.2
env : WP_VERSION=latest
- stage : test
php : 7.2
env : WP_VERSION=3.7.11
- stage : test
php : 7.2
env : WP_VERSION=trunk
Você pode apontar os testes para uma versão específica do WP-CLI através da constante WP_CLI_BIN_DIR
:
WP_CLI_BIN_DIR= ~ /my-custom-wp-cli/bin composer behat
Se quiser executar os testes de recursos em uma versão específica do WordPress, você pode usar a constante WP_VERSION
:
WP_VERSION=4.2 composer behat
A constante WP_VERSION
também entende o latest
e trunk
como destinos de versão válidos.
Por padrão, os testes são executados em um banco de dados denominado wp_cli_test
com o usuário também denominado wp_cli_test
com senha password1
. Isso deve ser configurado por meio do comando composer prepare-tests
.
As variáveis de ambiente a seguir podem ser definidas para substituir as credenciais padrão do banco de dados.
WP_CLI_TEST_DBHOST
é o host a ser usado e pode incluir uma porta, ou seja, "127.0.0.1:33060" (o padrão é "localhost")WP_CLI_TEST_DBROOTUSER
é o usuário que tem permissão para administrar bancos de dados e usuários (o padrão é "root").WP_CLI_TEST_DBROOTPASS
é a senha a ser usada para o usuário acima (o padrão é uma senha vazia).WP_CLI_TEST_DBNAME
é o banco de dados no qual os testes são executados (o padrão é "wp_cli_test").WP_CLI_TEST_DBUSER
é o usuário sob o qual os testes são executados (o padrão é "wp_cli_test").WP_CLI_TEST_DBPASS
é a senha a ser usada para o usuário acima (o padrão é "senha1").WP_CLI_TEST_DBTYPE
é o tipo de mecanismo de banco de dados a ser usado, ou seja, "sqlite" para executar testes em SQLite em vez de MySQL (o padrão é "mysql"). Variáveis de ambiente podem ser definidas para toda a sessão por meio da seguinte sintaxe: export WP_CLI_TEST_DBNAME=custom_db
.
Eles também podem ser configurados para uma única execução acrescentando-os antes do comando do Behat: WP_CLI_TEST_DBNAME=custom_db composer behat
.
Agradecemos por você ter tomado a iniciativa de contribuir para este projeto.
A contribuição não se limita apenas ao código. Incentivamos você a contribuir da maneira que melhor se adapta às suas habilidades, escrevendo tutoriais, fazendo uma demonstração em seu encontro local, ajudando outros usuários com suas dúvidas de suporte ou revisando nossa documentação.
Para uma introdução mais completa, confira o guia de contribuição do WP-CLI. Este pacote segue essas políticas e diretrizes.
Acha que encontrou um bug? Adoraríamos que você nos ajudasse a consertar isso.
Antes de criar um novo problema, você deve pesquisar os problemas existentes para ver se existe uma solução para ele ou se já foi corrigido em uma versão mais recente.
Depois de pesquisar um pouco e descobrir que não há um problema aberto ou corrigido para o seu bug, crie um novo problema. Inclua o máximo de detalhes possível e etapas claras para reprodução, se possível. Para obter mais orientações, revise nossa documentação de relatório de bugs.
Quer contribuir com um novo recurso? Primeiro, abra uma nova edição para discutir se o recurso é adequado para o projeto.
Depois de decidir dedicar tempo para ver sua solicitação pull, siga nossas diretrizes para criar uma solicitação pull para garantir que seja uma experiência agradável. Consulte "Configurando" para obter detalhes específicos sobre como trabalhar localmente neste pacote.
Os problemas do GitHub não são para questões gerais de suporte, mas existem outros locais que você pode tentar: https://wp-cli.org/#support