Testes de Integração e Testes E2E

[vitorbritto]

Na issue #43, o @lnfnunes me perguntou o seguinte:

@vitorbritto valeu pelos links!
Por favor, poderia me explicar melhor qual a diferença (prática), entre:

Testes de Integração: Pioneer
Testes de E2E: DalekJS

Me pareceu que com qualquer 1 dos dois eu consigo atingir o mesmo objetivo, então fiquei com essa dúvida do pq vc separou os dois em ferramentas diferentes.
Seria a questão das sintaxes ou envolve outros detalhes? Como vc utiliza no seu workflow?
Tks

Resolvi abrir uma issue para não perdermos o foco da discussão sobre testes de perfomance na #43 e falarmos um pouco mais sobre testes de integração e E2E (aceitação). =]

---

@lnfnunes legal você perguntar isso! 👍

Bom, alguns desenvolvedores confundem o princípio básico para os testes de integração e testes E2E.

Para mim, o Teste de Integração é realizado para cobrir o maior número possível de falhas entre componentes/módulos de um sistema. O princípio básico dos testes de integração é a verificação da estabilidade entre estes componentes em conjunto, bem como o fluxo apropriado dos dados entre eles. Você pode imaginar que um teste de integração é composto por vários testes unitários combinados entre sí, mas diferente dos testes unitários, os testes de integração fazem uso de qualquer meio necessário para comprovar que o código e o ambiente estejam adequados e seja candidato a ir para produção.

Já os Testes E2E são baseados em regras e/ou requisitos associados à uma ação do usuário. Você parte do princípio que deverão existir reações satisfatórias para determinadas ações na sua interface (sucesso em um redirecionamento a partir de um link clicado, a validação de um formulário, se o pagamento de um produto foi confirmado, se o produto foi adicionado ao carrinho corretamente, etc). Eu considero que os testes E2E estejam inseridos no contexto para os Testes de Aceitação.

E vocês? Utilizam ferramentas ou realizam testes de integração e aceitação também? =]

[doug2k1]

No projeto atual aqui a gente usa Karma e Jasmine pra testar o frontend de duas formas, tem os testes unitários mesmo, que mandam um input para uma função e certifica o que ela retorna. E também os testes "de integração" (não sei se nesse caso é esse o nome) do front, com o backend mockado, que executa ações (clica, preenche form) e verifica os resultados na tela (apareceu mensagem de erro, abriu a modal).

Temos também os testes E2E, usando Cucumber/Capybara, que aí testa tudo, front e back, também realizando ações como se fosse um usuário.

Confesso que me perco um pouco nas nomenclaturas (unitário, integração, funcional, regressão, e2e).

[lnfnunes]

Show @vitorbritto, ótima explicação!
Sobre minha dúvida, era um pouco mais sobre as ferramentas em si dq sobre a teoria.
Mas explicou muito bem e vou dedicar um tempo para conhecer melhor na prática como aplicar.

@doug2k1 tbém utilizo karma/jasmine normalmente. Gosto bastante da sintaxe e integrações do Jasmine.

Uma dica de ferramenta que deixo é o https://ghostinspector.com/.
É uma plataforma paga, porém oferece uma versão free. Basicamente oq ela permite é que de forma visual, vc vá clicando e ela monta o script. Acho muito boa principalmente para times onde os testers não possuem conhecimento técnico de escrever um script.

[vitorbritto]

@lnfnunes opa, obrigado! A dúvida me pareceu teórica também, mas vamos lá!

Ambas são bem tranquilas de manipular. Veja abaixo.

Pioneer

O Pioneer é um DSL em cima do WebDriver. Utiliza Cucumber para documentar e automatizar seus testes de foma objetiva. O escopo dos testes podem ser escritos com a ajuda da sintaxe Gherkin, o que torna simples de ler e escrever estes testes.

O Pionner faz um scaffolding ($ ./node_modules/.bin/pioneer --scaffold) com diretórios (features, fixtures, steps e widgets), um arquivo para sua feature (usando a sintaxe Gherkin, *.feature), um step inicial com base nessa feature e informações no seu package.json.

O processo do Pioneer é o seguinte:

1. Você escreve seus cenários, dentro do contexto da sua Feature no seu arquivo *.feature;
2. executa o teste para sua feature;
3. o processo automatizado é iniciado (start do browser, interações com o DOM e aplicação de estados);
4. caso falte algum step ele te retorna o que deve ser adicionado;
5. e assim o fluxo segure...

DalekJS

Olha esse comentário do @fdaciuk sobre o DalekJS.

Espero ter esclarecido sua dúvida.

Abraço! =]

[lnfnunes]

Show de bola @vitorbritto
Vou tentar aplicar aqui... tks!

[raphaklaus]

Boa discussão pessoal! Valeu pelas infos @vitorbritto

Eu já me aventurei nessas áreas também. Gostei muito do PhantomJS e DalekJS. Porém, o mais estável dos que testei foi o Selenium (usando NightwatchJS como JS Wrapper).

Uma pergunta, algum de vocês já usou o travis-ci ou serviço semelhante para realizar esse tipo de teste, especialmente em navegadores IE? Tem um projeto bem específico que terei algo do gênero, e esse tipo de teste só dá pra fazer em máquinas Windows...

Edit: Resolvi fazendo mocking de userAgent. ;)

[adrianoavelino]

@vitorbritto num teste E2E deve-se resetar o banco de dados e inserir os dados com as informações necessárias para cada cenário? Exemplo: para realizar um teste de login deve-se usar uma base de dados zerada, inserir o usuário com sua senha e demais informações e exclui-lo após cada teste ,como exemplo de teste temos: verificar campo login vazio, verificar campo senha vazio, verificar login invalido, verificar login de sucesso. Excluindo a base de dados e recriando para cada teste.

[didiraja]

Não mexo com testes ainda, mas o @fdaciuk participou de um Alura Live sobre Testes Automatizados, acredito que seja útil (ele comenta sobre DalekJS e outros mais modernos)

[fdaciuk]

O que eu falei que tinha esquecido o nome, que é bem legal também pra E2E é o cypress 😁

[nandomoreirame]

Fala pessoas, bacana essa discução aqui hein... vou contribuir tbm.
Recentemente na empresa onde trabalho aplicamos E2E usando o testeCafe, ele é bem limpo, usando ES6 usa classes, async e await... é bem bacana trabalhar com ele, testem ai e digam o que vcs acham. 👍

[fdaciuk]

Bem legal @nandomoreirame, curti! :D

[sbvorpagel]

Pessoal venho pesquisando mais sobre testes E2E para auxiliar os QAs da empresa na questão e sempre tive algumas duvidas e está discussão veio a calhar.

Sobre a granulariedade do teste E2E, como vocês trabalham?
Posso cobrir o E2E vendo um caminho do usuário e também poderia cobrir cada um dos requisitos que compõem esses ou vários caminhos. Ambos possuem vantagens e desvantagens principalmente na questão de tempo e custo de execução.

Outra questão é quando tenho um caminho do usuário que passa em A-B-C e agora entre A-B adicionei um novo requisito então ficaria A-N-B-C. Como vocês incorporam esse novo requisito nos testes? Ele ganha um teste apenas para ele ou o teste E2E anterior deve ser refatorado? Se eu apenas refatorar, eu não perco de alguma forma rastreabilidade?