Validar se usuário já está logado ou não ao executar cenário

[mariellems]

Possuo várias features que também tem vários cenários dentro delas, porém eu gostaria de desenvolver uma forma de validar a partir do "segundo cenário", se o usuário já está logado ou não, para não ter que repetir o login todas as vezes que inicia o próximo cenário. Estou utilizando Capybara + RSpec + Cucumber.

Desde já, agradeço.

[PauloGoncalvesBH]

@mariellems os testes são independentes um do outro? Você pode criar uma etapa de login que é executada antes de cada teste e logout após cada testes. Isso vai ajudar a não preocupar com o fato de estar logada ou não.

[mariellems]

@PauloGoncalvesBH, sim são independentes.

Antes de executar cada teste, eu tenho configurado no hooks.rb:

Before("@login_root") do
  user = CONFIG["users"]["root"]
  @login_page.go
  @login_page.with(user["email"], user["pass"])
end

Não sei se entendi a questão de fazer logout, sendo que não quero me deslogar do sistema, e sim logar uma única vez e rodar todos os cenários da feature.

[leoGalani]

Eu realmente não entendi muito bem a sua pergunta Marie :/ pode detalhar um pouco mais?

Você tem um hook global que efetua o login, porém vc gostaria de validar dentro dos cenários se vc realmente está logada para continuar o teste? Se for isso mesmo, é meio redundante, pois se você não der um driver.quit ou algo do tipo em um after hook, você tecnicamente ainda estará logada, mas isso pode ocasionar outros problemas como sessão suja, desconhecimento do estado atual da sessão, etc.

Eu particularmente utilizava esses hooks globais do cucumber para poder iniciar ou finalizar uma sessão do driver, fazer pos processamento com alguma lib de report, etc... mas não colocava nenhuma "regra" ou processo que tivesse relação ao negócio.

Você consegue ter steps que servem de pré condição para seus testes e acredito que esse deveria ser o local em que você deveria efetuar esse tipo de processo (que no seu caso é o de Login)

http://shipit.resultadosdigitais.com.br/blog/5-boas-praticas-para-uso-de-cucumber/

[mariellems]

@leoGalani, na verdade eu gostaria de validar de forma "geral" se o usuário está logado ou não, para que não seja necessário efetuar login toda vez que segue para o próximo cenário da feature. Eu tenho configurado no After para fechar o browser.

[mariellems]

Eu tenho a seguinte feature:

       @tarefas
        Funcionalidade: Tarefas
        Como um usuário do sistema
        Eu quero visualizar as tarefas cadastradas de acordo com cada status
        e também poder cadastrar novas tarefas, editar, excluir, filtrar tarefas

        @adicionarTarefas
        Esquema do Cenário: Adicionar tarefas

        Dado que acessei o cadastro de Tarefas
        Quando clicar em Adicionar nova tarefa no status A fazer
        E inserir um título <dados> para a tarefa
        E clicar no botão para confirmar a tarefa
        Então a tarefa com o título <dados> deve ser exibida na lista A fazer

        Exemplos:
        | dados     |
        | "tarefas" |

        @adicionarTarefasSemTitulo
        Cenário: Adicionar tarefas sem título

        Dado que acessei o cadastro de Tarefas
        Quando clicar em Adicionar nova tarefa no status A fazer
        E não inserir um título para a tarefa
        Então a tarefa não deve ser salva na listagem

Após rodar o cenário @adicionarTarefas e ir para o @adicionarTarefasSemTitulo, eu gostaria de que ele não refizesse o login, e sim, continuar logado no sistema, não sei se me fiz entender?

[leoGalani]

Acho que entendi o que vc quiz dizer... Voê queria um "hook" para executar somente uma vez antes de todos os testes e uma vez depois de todos os testes.. certo?

Olha... no tempo que eu usei cucumber, esse era um grande problema da ferramenta e um uma pequena busca na internet mostra algumas gambiarras para fazer isso funcionar de um jeito bem problematico.

A propria documentação reinteira para não usar nada de negócio nos hooks before e aflter https://cucumber.io/docs/cucumber/api/

Whatever happens in a Before hook is invisible to people who only read the features. You should consider using a background as a more explicit alternative, especially if the setup should be readable by non-technical people. Only use a Before hook for low-level logic such as starting a browser or deleting data from a database.

Talvez eu esteja fazendo um overengineering aqui MAS se vc realmente quer manter a sessão e nao fechar o browser a cada teste, eu criaria um rake task para abrir e fechar o browser depois que o processo de teste esteja finalizado, usar background de que o usuario ˆprecisa estar logadoˆ e nesse step eu faria a validação de que se ele esta logado, nao faz nada.. se não tiver, efetua o login. (eu nunca fiz isso.. mas acho que de pra fazer... rsrs)

Quem manja mais de cucumber e gosta de passar nervoso com ele é o @ramses ... vo pedir pra ele dar um pitaco aqui tb

[mariellems]

@leoGalani como eu crio um "rake task"? rsrs preciso de help, não manjo muito de cucumber =/

[leoGalani]

Olá @mariellems .. na verdade rake é um processo de tarefas do ruby.. não tem nada a ver com cucumber...

Eu dei a ideia de inicializar o browser em uma rake task para nao ter que usar os hooks padrão do cucumber mas talvez a instancia do browser teria que ser global e isso não é uma boa pratica.

Tem algum motivo muito forte para manter o usuário logado para fazer todos os seus testes? É uma boa pratica não ter interdependencia entre seus testes, ou seja, seu teste tem que começar e finalizar dependendo somente do que ele produz ou do background vinculado a ele.

Isso vai aumentar sua code base um pouco e talvez force você a escrever de outra forma seus cenarios em gerhkin, mas no longo prazo esse isolamento se paga (diminuindo complexidade e falsos negativos)

[mariellems]

Bom dia @leoGalani , então, isso veio de um pedido acima de mim, por este motivo estou pesquisando formas e tentativas de manter o usuário logado em todos os testes, mas como não entendo muito de programação também, pra mim está um tanto confuso, e concordo com vc em relação a interdependência dos testes.

[leoGalani]

Assim.. da uma questionada sobre os motivos, talvez essa decisão seja para deixar os testes mais rapidos? ou talvez para economizar recursos? Sabendo um pouco dos motivos que vieram de cima, da pra fazer sugestões mais acertivas para sua situação :)

[mariellems]

@leoGalani eu acredito que seja a opção 1, para tornar os testes mais rápidos, mas vou questionar isso mais a fundo ;)

[leoGalani]

Para tornar os testes mais rapidos, você pode paralelizar a execução dos cenarios, verificar se nao o tempo de loading das dependencias para entender se é possivel otimizar... etc..

da uma lida nisso aqui também para executar testes paralelos --> https://github.com/grosser/parallel_tests

Outra coisa.. quando vc executa testes em paralelo, vc vai realmente precisar de testes independentes senão vai dar uns erros de fluxo e vai ficar ainda pior de debugar :/

[mariellems]

Obrigada @leoGalani. Mais uma dúvida, em relação aos testes executados em ferramenta CI, como Jenkins, é uma boa prática criar apenas uma job para rodar todos os cenários nela? Pergunto pq, em experiências anteriores, eu costumava criar uma job para cada cenário ou feature pelo menos.

[leoGalani]

@mariellems pelo que vi no seu exemplo, vc já usa @tags para seus cenarios e com isso você pode agrupar a execução dos seus testes em profiles ou por linha de comando mesmo vc consegue executar somente testes com as tags que vc quer

Exemplo de varias tags:

@smoke @tarefas @tag_aleatoria
Funcionalidade: Tarefas

exemplo de execução:

cucumber --tags "@tarefas and @smoke"

Documentação: https://cucumber.io/docs/cucumber/api/

Refatorando as tags que você usa, da pra criar profiles especificos para executar essas tags e vc pode criar jobs especificos que executem somente aquele profile, e sim, é uma boa pratica vc agrupar seus testes em grupos para vacilitar debug e organização e tracking de tempo de execução.

[mariellems]

@leoGalani entendo que agrupando os testes em tags é sim, é uma boa prática. Porém, criar apenas um Job para executar todos os testes, na minha opinião, não é uma boa saída, certo? Tipo, criei um job para rodar todos os testes sequencialmente.

[leoGalani]

Sim.. ter somente um job que executa todos os testes ( e pelo jeito que estão, são sequenciais ) não escala :/