How Guru’s Engineers Use Cypress for Better Burn Testing
Precisa de uma maneira melhor de lidar com testes de carga? Dois de nossos engenheiros de front end encontraram uma maneira de usar Cypress para melhorar a forma como lidam com QA.
Nós somos todos sobre compartilhamento de conhecimento na Guru, e quando descobrimos algo novo e útil, queremos que o mundo saiba! Nossa equipe de engenharia usa Cypress em seus testes e no processo de QA. Eles descobriram uma nova maneira de ajudar a realizar melhores testes de carga, e querem compartilhar seu novo e aprimorado processo com outros engenheiros e testadores.
No último ano, temos nos concentrado em aumentar nossa cobertura de testes — especificamente, testes de ponta a ponta que garantem que diferentes partes de nossos fluxos de produto funcionem corretamente à medida que fazemos atualizações de código. Para esse tipo de teste, aproveitamos uma ferramenta chamada Cypress que simula o comportamento do usuário com nosso aplicativo web e a extensão Google Chrome. Esse conjunto de testes é executado em cada solicitação de pull para garantir que o novo código não quebre nada em nossa interface. Também queremos impedir que versões sejam lançadas se nossa suíte Cypress falhar em nossa branch de produção.
O que procuramos em testes tradicionais
Um dos problemas que lidamos é ver alguns de nossos testes falharem, mas não por razões ligadas à interface ou ao código. Então, como o Cypress nos ajuda nesses casos? Fazemos o Cypress agir como um usuário cujo comportamento podemos definir. Existem várias variáveis que podem levar o Cypress a nos informar que há uma falha, mas da perspectiva do usuário, nada parece estar errado.
Por exemplo, pode haver um teste que diz: “Vá para esta parte do aplicativo web > Adicione um novo cartão Guru > Espere ver um estado pós-criação”. Se o estado de carregamento da criação de um cartão demorar um milissegundo a mais e o Cypress começar a procurar o estado pós-criação antes que ele esteja lá, esse teste pode falhar (na maior parte do tempo, porém, esse teste passará). Se passar uma vez em uma solicitação de pull, podemos mesclar código que às vezes pode falhar. Mas não saberemos se é assim; um teste bem-sucedido não é garantia de que o código está correto.
Esse tipo de situação diminui a confiabilidade de nossa cobertura de testes. Como resultado, quando uma falha de teste aparece em nosso pipeline de implantação, precisamos verificar se é um problema com a interface — ou com o teste. Para corrigir isso, começamos a pensar em maneiras de detectar se um teste pode falhar antes que ele vá para nossa branch de código de produção.
Como os testes de carga ajudam
Entrar nos testes de carga. Os testes de carga são um processo usado para testar algo sob condições mais rigorosas ou extremas. Às vezes também é chamado de teste de estresse ou teste de carga, dependendo do método ou área específica que está sendo testada.
Na Guru, usamos testes de carga como parte de nossa suíte Cypress para qualquer teste novo ou modificado que seja adicionado ao nosso código. Antes que esses testes possam ser mesclados, os executamos várias vezes consecutivas e todos devem passar para avançar para a próxima etapa em nosso pipeline de build do CircleCI.
Esta etapa acontece imediatamente antes de executarmos toda a suíte de testes Cypress. A vantagem dessa ordem é que se nossa etapa de teste de carga produz uma falha, podemos marcar toda a verificação como uma falha mais cedo. Pular o restante da suíte nos permite economizar tempo e reduzir o número de ciclos que pode levar para garantir que os testes recém-introduzidos sejam tão confiáveis e tolerantes a falhas quanto precisamos.
Para encontrar os arquivos que buscamos, usamos git diff na branch atual e fornecemos a saída como parâmetro para uma ferramenta chamada cypress-repeat que nos permite executar esses testes um número especificado de vezes, adicionando efetivamente testes de carga como uma etapa em nossa suíte de testes de ponta a ponta.
O resultado
Fazer essa alteração em nossos planos de testes teve alguns resultados bastante positivos. Para nós, adicionar testes de carga pode reduzir o tempo que leva para encontrar testes não confiáveis em até 30 minutos. Isso também melhora o tempo de resposta para adicionar nova funcionalidade. Uma vez que os testes recém-adicionados agora são executados primeiro, eles nos permitem verificar a estabilidade antes de continuar com o restante do processo de build.
No geral, nosso foco contínuo em tornar nossos processos de teste mais eficientes e robustos aumenta a confiança de toda a equipe de engenharia em enviar novos recursos rapidamente. Estamos corrigindo bugs mais rapidamente e tornando mais fácil trabalhar em todos os nossos códigos. Esperamos que este post ajude outros usuários do Cypress a criar testes melhores e equipes inteiras a construir mais eficientemente.
Nós somos todos sobre compartilhamento de conhecimento na Guru, e quando descobrimos algo novo e útil, queremos que o mundo saiba! Nossa equipe de engenharia usa Cypress em seus testes e no processo de QA. Eles descobriram uma nova maneira de ajudar a realizar melhores testes de carga, e querem compartilhar seu novo e aprimorado processo com outros engenheiros e testadores.
No último ano, temos nos concentrado em aumentar nossa cobertura de testes — especificamente, testes de ponta a ponta que garantem que diferentes partes de nossos fluxos de produto funcionem corretamente à medida que fazemos atualizações de código. Para esse tipo de teste, aproveitamos uma ferramenta chamada Cypress que simula o comportamento do usuário com nosso aplicativo web e a extensão Google Chrome. Esse conjunto de testes é executado em cada solicitação de pull para garantir que o novo código não quebre nada em nossa interface. Também queremos impedir que versões sejam lançadas se nossa suíte Cypress falhar em nossa branch de produção.
O que procuramos em testes tradicionais
Um dos problemas que lidamos é ver alguns de nossos testes falharem, mas não por razões ligadas à interface ou ao código. Então, como o Cypress nos ajuda nesses casos? Fazemos o Cypress agir como um usuário cujo comportamento podemos definir. Existem várias variáveis que podem levar o Cypress a nos informar que há uma falha, mas da perspectiva do usuário, nada parece estar errado.
Por exemplo, pode haver um teste que diz: “Vá para esta parte do aplicativo web > Adicione um novo cartão Guru > Espere ver um estado pós-criação”. Se o estado de carregamento da criação de um cartão demorar um milissegundo a mais e o Cypress começar a procurar o estado pós-criação antes que ele esteja lá, esse teste pode falhar (na maior parte do tempo, porém, esse teste passará). Se passar uma vez em uma solicitação de pull, podemos mesclar código que às vezes pode falhar. Mas não saberemos se é assim; um teste bem-sucedido não é garantia de que o código está correto.
Esse tipo de situação diminui a confiabilidade de nossa cobertura de testes. Como resultado, quando uma falha de teste aparece em nosso pipeline de implantação, precisamos verificar se é um problema com a interface — ou com o teste. Para corrigir isso, começamos a pensar em maneiras de detectar se um teste pode falhar antes que ele vá para nossa branch de código de produção.
Como os testes de carga ajudam
Entrar nos testes de carga. Os testes de carga são um processo usado para testar algo sob condições mais rigorosas ou extremas. Às vezes também é chamado de teste de estresse ou teste de carga, dependendo do método ou área específica que está sendo testada.
Na Guru, usamos testes de carga como parte de nossa suíte Cypress para qualquer teste novo ou modificado que seja adicionado ao nosso código. Antes que esses testes possam ser mesclados, os executamos várias vezes consecutivas e todos devem passar para avançar para a próxima etapa em nosso pipeline de build do CircleCI.
Esta etapa acontece imediatamente antes de executarmos toda a suíte de testes Cypress. A vantagem dessa ordem é que se nossa etapa de teste de carga produz uma falha, podemos marcar toda a verificação como uma falha mais cedo. Pular o restante da suíte nos permite economizar tempo e reduzir o número de ciclos que pode levar para garantir que os testes recém-introduzidos sejam tão confiáveis e tolerantes a falhas quanto precisamos.
Para encontrar os arquivos que buscamos, usamos git diff na branch atual e fornecemos a saída como parâmetro para uma ferramenta chamada cypress-repeat que nos permite executar esses testes um número especificado de vezes, adicionando efetivamente testes de carga como uma etapa em nossa suíte de testes de ponta a ponta.
O resultado
Fazer essa alteração em nossos planos de testes teve alguns resultados bastante positivos. Para nós, adicionar testes de carga pode reduzir o tempo que leva para encontrar testes não confiáveis em até 30 minutos. Isso também melhora o tempo de resposta para adicionar nova funcionalidade. Uma vez que os testes recém-adicionados agora são executados primeiro, eles nos permitem verificar a estabilidade antes de continuar com o restante do processo de build.
No geral, nosso foco contínuo em tornar nossos processos de teste mais eficientes e robustos aumenta a confiança de toda a equipe de engenharia em enviar novos recursos rapidamente. Estamos corrigindo bugs mais rapidamente e tornando mais fácil trabalhar em todos os nossos códigos. Esperamos que este post ajude outros usuários do Cypress a criar testes melhores e equipes inteiras a construir mais eficientemente.
Experimente o poder da plataforma Guru em primeira mão - faça nosso tour interativo pelo produto
