Práticas recomendadas para testar regressão em sites WordPress?

Olá a todos,

Gostaria de ouvir o que outras pessoas que estão oferecendo soluções complexas que não são de blog para clientes com o WordPress como plataforma, o que estão usando para o teste de regressão automatizado ?

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 após a realização de alterações no programa (por exemplo, correções de bugs ou nova funcionalidade), testando novamente o programa. A intenção do teste de regressão é garantir que uma alteração, como uma correção de bug, não introduza novos bugs.

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

A experiência mostrou que, à medida que o software é corrigido, o surgimento de novas e / ou reemergências de falhas antigas é bastante comum. Às vezes, o ressurgimento ocorre porque uma correção é perdida devido a práticas inadequadas de controle de revisão (ou erro humano simples no controle de revisão). Freqüentemente, uma correção para um problema é "frágil", pois corrige o problema no caso estreito 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 inadvertidamente causa um erro de software em outra área. Finalmente, geralmente ocorre que, quando algum recurso é redesenhado, alguns dos mesmos erros cometidos na implementação original do recurso foram cometidos no redesenho.

Com a natureza global de ações e filtros, percebo que a complexidade começa a aumentar à medida que adiciono mais funcionalidade solicitada pelo cliente e fica difícil obter um plugin complexo estável, especialmente se ele usa muitas chamadas WP_Querye 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 é tão difícil quando você está testando a saída HTML de solicitações HTTP GET. Mas fica um pouco mais complicado quando você precisa testar as coisas quando está conectado 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 reunir as melhores práticas aqui, mas estou realmente ansioso para ouvir processos, se outros profissionais do WordPress estiverem usando.

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

Mais a sério, você pode testar seus plugins o quanto quiser do ponto de vista funcional com testes de unidade e similares. O problema é que esses testes não garantem que eles tenham chances sutis introduzidas pelas atualizações do WP, muito menos que continuem a trabalhar depois de conectados a uma instalação personalizada do WP.

Entre as coisas coloridas que eu vi acontecer:

• Uma mudança sutil na API do WP afeta a funcionalidade do plug-in, por exemplo, o gancho usado para obter um ID de termo e agora está recebendo um ID de taxonomia de termo. (É provável que seus termos de teste tenham convenientemente o mesmo ID para ambos).

• Uma mudança sutil na API do WP resulta no recebimento de um WP_Errorobjeto em vez do valor anteriormente esperado de falseentrada incorreta.

• Seu plug-in é adicionado de dentro 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 seja ativado.

• Seu plugin funcionou bem até o desprezado switch_to_blog () ser 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?) Intencionalmente mexe com seus dados de entrada ou saída até o ponto em que as coisas parecem quebradas, mesmo que você não tenha culpa.

Eu poderia expandir a lista sem parar, mas esses seriam os itens principais 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 contornará a implementação de bugs do switch_to_blog (). E os dois últimos são irremediavelmente não testáveis.

Ah, e ... nem me inicie no ataque de anexos, rascunhos automáticos, revisões, itens de menu e o que não é que acaba armazenado na tabela de postagens.

Boa sorte... :-)

Você deve considerar fortemente o selênio .

Permite gravar ações (por exemplo, inserir dados em um formulário, clicar em um link) e, em seguida, você pode executar asserções. Também se integra ao PHPUnit. Eu recomendo conferir a demonstração de dois minutos.

O selênio é provavelmente utilizável, mas acho que nos tempos modernos você achará a codecepção melhor e mais fácil de usar. Para o teste de regressão visual mais simples , ele possui uma extensão que captura capturas de tela e as compara automaticamente para você.

Obviamente, os testes do Codeception WebDriver podem ir além e executar 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 o Firefox ou Chrome em seus testes, ou pode executar testes sem cabeça com o PhantomJS . Isso significa que você pode até executar os testes do WebDriver para seu plug-in como parte do processo de criação no Travis CI, se desejar.

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

• Navegador WP
• Codecepção WP