Ensaio unitário de um projecto de selénio

Question

Ensaio unitário de um projecto de selénio

uma pergunta sobre as melhores práticas ou práticas;]

estou actualmente a trabalhar num sistema de automatização de testes utilizando selénio em Java. É suposto ser usado para testes de aceitação final-a-final de um webapp. Os casos de teste são escritos na língua Gherkin e executados pelo pepino framework BDD (Cucumber-JVM). As funções de baixo nível usam o selênio/WebDriver para interagir com o AUT e o navegador. O código de selénio está estruturado usando o padrão de PageObject que abstrai o uso do WebDriver. As definições de etapa de pepino chamam apenas os métodos fornecidos pelos PageObjects.

à medida que o projecto continua e se torna cada vez mais complexo, gostaria de começar a escrever um teste de unidade para garantir que os testes de aceitação, e as funções de utilidade em torno desses, façam o que devem:)

passemos agora à pergunta::

É possível fazer um teste de unidade para testar um projecto de automatização de testes?

o principal problema é que durante minha primeira abordagem ao teste de unidade usando TestNG eu percebi, que meus testes de unidade acabaram fazendo mais ou menos a mesma coisa que os testes de aceitação já fizeram. Isto é contraproducente, pois os testes unitários são muito lentos e têm muitas dependências.

ou testamos apenas as classes de utilidade e deixamos o código de selénio em tal caso. ie. testar apenas as coisas que podem ser testadas sem ligar para o WebDriver selénio e interagir com a AUT?

Nota só para ter a certeza Não fui mal interpretado. Estou a perguntar sobre o teste de unidade no código de aceitação e em todo o código auxiliar. Não se trata de executar os casos de teste de selénio usando uma estrutura de teste de unidade como JUnit ou TestNG.

qualquer ajuda e/ou ideias serão apreciadas, pois não tenho a certeza de como lidar com esta. Isto se os testes de escrita para testes for de todo sensato;)

1

java unit-testing selenium cucumber

Author: namarath, 2016-05-23

Source

2 answers

Pessoalmente, não escreveria um código de teste que testasse o código de teste. Escrever testes para me proteger de erros na 3:ferramentas do partido rd como o selénio não é algo que eu fizesse. Se os testes passarem e o resultado esperado for validado, isso será suficiente para mim. Quando eu atualizasse para uma nova versão do selênio, faria isso quando tivesse um estado de trabalho. Ou seja, todos os testes passaram. A única alteração seria a versão selênio. Se eu agora tenho testes que quebram, eu sei que Selênio está se comportando de forma diferente nesta versão do que eu esperava e pode agir de acordo. Eu escreveria testes para qualquer funcionalidade de utilidade complicada que precisasse. Eu, no entanto, trabalharia duro para escrever o código de teste extremamente fácil de entender e evitar qualquer coisa remotamente complicada nele. E então tenha o cuidado de verificar que cada teste verificou o comportamento que eu estou esperando.

0

Author: Thomas Sundberg, 2016-05-25 05:54:14

score 2 · Accepted Answer

Tenho a certeza que alguém considerará a minha resposta "opinativa"e votará contra, mas mesmo assim acho que ...

Sim, se você tem um framework de teste que você está confiando para seu teste de aceitação, o framework em si precisa ser testado.

Pela minha experiência, o valor está em 2 áreas:

Seja capaz de mudar o seu quadro com confiança. Quando você cria alguma função, você sabe bastante sobre ela, ou seja, que usa casos que ela Suportes, o que foi projetado para fazer, etc. Mas outras pessoas (ou mesmo você daqui a um ano) podem não ter o mesmo nível de conhecimento, mesmo com documentação. Então, ou novas funções irão aparecer sempre que alguém precisa de alguma ligeira modificação no comportamento (porque não está confiante em mudar a função existente), ou alguém pode quebrar um monte de testes de aceitação.

É melhor se forem testes de unidade verdadeiros, capazes de funcionar completamente independentemente de qualquer coisa (usar caretas, estática predefinida dados de ensaio, etc.).
Proteja-se de alterações / bugs inesperadas no próprio selênio (ou outras importantes bibliotecas de terceiros). Quando você está atualizando selênio para a próxima versão (e que normalmente precisa ser feito a cada 3-6 meses), há sempre uma chance de que eles mudaram algum padrão que você estava confiando (e nem sabia), ou quebrou alguma coisa, ou de repente algo retorna uma exceção diferente, ou não lança exceção onde ele fez anteriormente e assim por diante. É claro que não há necessidade de se entusiasmar e duplicar os testes da própria unidade de selênio, mas quando se trata de coisas não triviais, ou confiar em alguns recursos com documentação pobre, esses testes podem ajudar muito.
São testes de integração. Idealmente, eles devem correr contra o webapp test-only (não a aplicação real) que replicam comportamentos especificamente testados de uma forma conveniente para os testes.

É claro que alguns compromissos também são possíveis. Por exemplo, ter um pequeno subconjunto de testes de aceitação que estão servindo como testes de unidade / integração (eles executam primeiro, e outros testes só funcionam se eles estão passando). Pode ser mais barato começar com esses e migrar lentamente para testes de unidade/integração adequados quando você depurar / corrigir problemas no framework de teste.

Outra questão é como separar os testes que testam a sua estrutura dos testes de aceitação reais para o produto. O que funcionou para mim é manter o quadro de testes e testes de aceitação em dois projetos separados. Assim posso alterar o framework, construí-lo (que também inclui a execução de testes de unidade e integração) muitas vezes, se necessário. Quando todos os testes de unidade e integração estão passando, então eu posso atualizar a versão usada pelos testes de aceitação reais.