2
respostas

Duvida sobre os testes

Estou gostando muito do curso, porém estou com algumas duvidas

1) Em um preenchimento de formulário, o correto seria utilizar o Theory passando todas as possibilidades no InlineData ou criar um método para cada campo?

2) Em uma aplicação com varias paginas, devo criar uma classe para cada página?

3) Qual o nome da convenção utilizada para criar o nome dos metodos e essa é a melhor convenção? pois achei o nome exagerado

4) Em uma aplicação que necessita de login, a cada teste que for executado, vai ser necessário realizar o login? existe alguma forma de, primeiro logar e depois realizar todos os testes?

5) Existe alguma boa prática para comentários nos testes? é bom colocar comentário em cada método explicando o que ele faz?

2 respostas

Outra duvida, é possivel alterar a ordem dos testes? porque no meu caso está dando problema nos seguintes testes:

1) o teste realiza login de forma correta e acessa a plataforma

2) o teste tenta realizar login de forma incorreta, porém o primeiro teste ja acessou a plataforma, e não está mais na pagina de login

eu precisava trocar a ordem dos testes 1 e 2, para que primeiro seja realizado teste de forma incorreta e só no final realize de forma correta

Olá Felipe, tudo certo?

Vamos lá:

  1. O InlineData serve para testar vários valores diferentes. Um lugar bom para usar isso, seria na verificação para registrar um usuário novo. Talvez usando algumas linhas de verificações que sempre terá algum dado inválido e como resultado, nunca iria para a página de confirmação de registro.

  2. Seria bem interessante criar uma classe de testes para cada tipo de verificação. Numa página, pode-se verificar se o usuário está logado, se contém o formulário para registro (note que os dois testes não deveriam existir em conjunto). Se a página não tiver tantas necessidades de verificações, pode fazer uma por página, mas o ideal é quebrar suas classes para testes específicos.

  3. O teste tem que indicar o que ele está fazendo. Se o nome não for específico o suficiente, terá que deixar bem documentado o que ele testa. Não faria muito sentido um teste que tem um nome curto, não tem documentação e quando ele quebra, precisa analisar o teste para saber o que ele faz. Acredito que o nome grande é um bom caminho, assim, quem está testando consegue saber o que está em teste e o que está funcionando corretamente.

  4. Acredito que uma boa forma, seria fazer os testes deslogados e após todos eles ficarem prontos, iniciar os testes logados. A partir da segunda aula, onde começa a compartilhar o recurso do navegador, esse navegador só será fechado depois que todos os testes forem executados. Ainda não vi o conteúdo do segundo curso, pode ser que tenha algo lá também sobre o assunto.

  5. Se o nome da classe e do teste não forem auto-explicativos, é sim uma ótima ideia documentar certinho o que está acontecendo. Mas realmente seria legal documentar algumas classes, como as Page Objects e as Fixtures.

  6. Vi que tem alguns meios de fazer isso. Com NUnit, com um código meio complexo, mas acho que uma solução, seria você dividir em coleções (do CollectionFixture). Uma você inclui os testes deslogados e na outra você inclui os dados logado, já que cada CollectionFixture irá compartilhar um navegador. Acha que seria uma solução?

Bom espero que tenha ajudado!