Práticas recomendadas para regressão testando sites WordPress?

21

Olá a todos,

Gostaria de saber o que outras pessoas que estão fornecendo soluções complexas que não são de blog para clientes com o WordPress como plataforma, o que elas estão usando para automatizar Teste de regressão ?

Para aqueles que não estão familiarizados com o termo "teste de regressão" , a Wikipedia define como:

  

Teste de regressão é qualquer tipo de teste de software que procura descobrir erros de software depois que mudanças no programa (por exemplo, correções de bugs ou novas funcionalidades) foram feitas, testando novamente o programa. A intenção do teste de regressão é garantir que uma alteração, como uma correção de bugs, não introduza novos bugs.

Mais dizendo Wikipedia diz o seguinte, que é exatamente o que estou experimentando em um projeto agora:

  

A experiência mostrou que, como o software é fixo, o surgimento de novos e / ou ressurgimentos de falhas antigas é bastante comum. Às vezes, a reemergência ocorre porque uma correção é perdida por meio de práticas inadequadas de controle de revisão (ou erro humano simples no controle de revisão). Muitas vezes, uma correção para um problema será "frágil" na medida em que resolve o problema no caso restrito em que foi observado pela primeira vez, mas não em casos mais gerais que podem surgir durante a vida útil do software. Freqüentemente, uma correção para um problema em uma área causa inadvertidamente um bug de software em outra área. Por fim, muitas vezes, quando algum recurso é redesenhado, alguns dos mesmos erros que foram cometidos na implementação original do recurso foram feitos no novo design.

Com a natureza global de ações e filtros, estou descobrindo que a complexidade começa a aumentar à medida que adiciono mais funcionalidades solicitadas pelo cliente e fica difícil conseguir um plugin complexo estável, especialmente se ele usa muitas chamadas para WP_Query e atualiza muito o banco de dados.

A solução em minha mente seria configurar o teste de regressão com uma série de "casos de teste" para incluir um "conjunto de testes". No conceito não é isso difícil quando você está testando a saída HTML de solicitações HTTP GET. Mas fica um pouco mais complicado quando você tem que testar coisas quando logado através do console de administração e / ou testar as interações do jQuery.

Estou configurando isso como um wiki da comunidade na esperança de podermos reunir as melhores práticas aqui, mas estou realmente ansioso para ouvir os processos se outros profissionais do WordPress estiverem usando.

    
por MikeSchinkel 02.12.2010 / 06:40
fonte

3 respostas

10

O PHPUnit viria à mente, se o pacote de testes do WP não estivesse tão quebrado, e se o WP tivesse sido projetado e escrito de uma forma que pudesse ser testado de maneira apropriada. ; -)

Mais a sério, você pode testar seus plug-ins o quanto quiser do ponto de vista funcional, com testes de unidade e afins. A questão é que esses testes não garantem que eles vão pegar chances sutis introduzidas pelos upgrades do WP, e muito menos que eles continuarão a trabalhar uma vez conectados a uma instalação personalizada do WP.

Entre as coisas coloridas que vi acontecer:

  • Uma alteração sutil na API do WP afeta a funcionalidade do seu plug-in, por exemplo, o gancho em que você está acostumado a obter um ID de termo e agora está obtendo um ID de taxonomia de termo. (As chances são boas de que seus termos de teste tenham convenientemente o mesmo id para ambos).

  • Uma alteração sutil na API do WP resulta no recebimento de um objeto WP_Error em vez do valor esperado anteriormente de false como entrada inválida.

  • Seu plug-in é adicionado a partir da pasta mu-plugins, resultando em um fluxo de código sutilmente diferente.

  • Seu plug-in funcionou bem até que o memcached ou algum outro armazenamento persistente tenha sido ativado.

  • Seu plugin funcionou bem até que o desprezado switch_to_blog () foi chamado.

  • Um plug-in altera o gancho no qual ele reside quando chamado e, sem saber, o interrompe como um efeito colateral.

  • Um plug-in (un?) conscientemente interfere nos dados de entrada ou saída, até o ponto em que as coisas parecem estar quebradas, mesmo que você não seja o culpado.

Eu poderia expandir a lista, mas esses seriam os principais itens que quebraram meus próprios plugins. Os dois itens são discutíveis com testes de unidade. Os próximos dois também, se você for paciente o suficiente, mas eu diria que o WP não deve mudar a maneira como as coisas funcionam quando ocorrem. Nenhuma quantidade de testes funcionará em torno da implementação de bugs do switch_to_blog (). E os dois últimos são impossivelmente testáveis.

Ah, e ... nem sequer me iniciei no ataque de anexos, rascunhos automáticos, revisões, itens de menu e o que não acabou armazenado na tabela de posts.

Boa sorte ...: -)

    
por Denis 02.12.2010 / 12:51
fonte
7

Você deve considerar strongmente o Selênio .

Ele permite que você registre ações (por exemplo, inserindo dados em um formulário, clicando em um link) e, em seguida, pode executar afirmações. Também se integra com o PHPUnit. Eu recomendo strongmente verificar a demonstração de dois minutos.

    
por Ethan Seifert 04.12.2010 / 01:37
fonte
1

O selênio é provavelmente utilizável, mas acho que nos tempos modernos você encontrará Codeception para ser melhor e mais fácil de usar. Para o teste de regressão mais simples visual , ele ainda tem uma extensão que fará capturas de tela e os compare automaticamente para você.

Naturalmente, os testes WebDriver do Codeception podem ir além e realizar testes de regressão funcional . Você pode preencher e enviar formulários, clicar em botões e links no site, executar qualquer JS, etc. Você pode usar um navegador da vida real, como Firefox ou Chrome, em seus testes, ou você pode realizar testes sem cabeça com PhantomJS . Isso significa que você pode até executar os testes do WebDriver para o seu plugin como parte de seu processo de criação no Travis CI se você quiser.

Existem até várias bibliotecas específicas do WordPress para ajudar você a começar:

por J.D. 01.09.2016 / 18:28
fonte