Olá a todos da comunidade OpenRedu! Meu nome é Pablo Timoteo do Nascimento, estudante do curso de Sistemas de Informação da Universidade Federal de Pernambuco, e escrevo esse post juntamente com Márcio Wendell Monteiro Cavalcanti, estudante do mesmo curso.
Se você que está lendo esse post é iniciante ou leigo no assunto, gostaria de lhe tranquilizar agora mesmo! Pois garanto que você em 3 dias(muito possivelmente bem menos) você já estará criando seus cenários e caso de teste com tranquilidade. É completamente normal já entender como funciona o CodeceptJS. mas se você já tem experiência com testes ou só quer começar a aprender como contribuir com o projeto criando testes automatizados, pode pular para sessão Como funciona o CodeceptJS
Nossa proposta é justamente criar testes ponta a ponta na aplicação com a finalidade de garantir que as funcionalidades principais estejam funcionando. Porém, existe a preocupação sobre a curva de aprendizado de novos colaboradores. Uma vez que quanto menor for a barreira de entrada, mais fácil será a adição de novas contribuições. Por isso nós adotamos o uso do BDD usando a ferramenta CodeceptJS.
Primeiramente, o Behavior Driven Development é um técnica de desenvolvimento ágil que estimula a colaboração entre todos os envolvidos no projeto(não só os desenvolvedores), gerando um comportamento esperado e fazendo o desenvolvimento a partir dele, na prática, o BDD é um complemento do TDD. Para tal colaboração, pessoas com entendimento técnico e pessoas sem conhecimento técnico precisam ter um bom entendimento de como funciona o sistema e é aí que entra a linguagem Gherkin. O Gherkin é um dos elementos principais quando se trata de BDD em automação, através dele é possível criar especificações em linguagem natural baseadas nas regras de negócio. Por isso, qualquer pessoa através do gherkin pode entender o funcionamento do sistema.
Por tudo isso, precisamos de uma ferramenta que facilite o uso do BDD para que possamos aplicar na prática todos os benefícios dessa técnica e a ferramenta escolhida foi o CodeceptJS. O CodeceptJS é uma ferramenta de automação de testes ponta a ponta que possui algumas facilidades para implementar os conceitos do BDD. Basicamente, a aplicação do gherkin permite que sejam escritos cenários usando linguagem natural, de maneira amigável a qualquer pessoa, e a partir desses cenários implementar comportamentos correspondentes. No fim, não é uma simples garantia que o sistema funciona, sem cor e sim uma história de como o sistema funciona, algo vivo.
Como funciona o CodeceptJS
Indo pra prática, no diretório codeceptjs contida no OpenRedu existem dois principais que vão guardar as contribuições, isto é, adição de novos testes estes são:
features
É o diretório que vai armazenar todos os arquivos relativos às funcionalidades do OpenRedu, basicamente cada arquivo representa uma funcionalidade e cada cenário contido neste arquivo representa um comportamento a ser testado dentro do projeto.
Esses arquivos devem ter o seguinte nome: funcionalidade.feature.
Ao abrir qualquer um desses arquivos e ler rapidamente qualquer cenário de teste você vai notar que é muito fácil de entender exatamente sobre o que se trata cada cenário e seu passo a passo. Essa facilidade toda se deve ao fato de como o BDD e o Gherkin atuam juntos onde basicamente ele possui keywords ou palavras-chave, se preferir; palavras-chave essas que ditam o fluxo de ações dos testes criados, vamos às palavras chaves:
- Given (Dado/ dado que): Basicamente denota uma pré-condição que é necessária para prosseguir para o próximo passo. Normalmente essa keyword é a primeira keyword a aparecer nos cenários de teste
- When (quando): Utilizamos essa keyword quando irá ser executada uma ação da qual nós esperamos uma reação vinda do sistema.
- Then (Então): é onde validamos se o esperado aconteceu.
- And (E): É uma keyword que basicamente serve para complementar as outras já mencionadas, caso seja necessário mais de um uso seguido de alguma keyword, ao invés de repetirmos ela, podemos simplesmente usar o And que já será o suficiente e ficará ainda mais natural em questão de leitura.
- But (Mas): Não foi utilizada em nossas contribuições, mas basicamente, serve de maneira parecida com o But, mas é normalmente utilizado após uma validação negativo depois do “Then”
Estrutura normal de um cenário
Scenario: Descrição do cenário
Given Descrição do passo 1
When Descrição do passo 2
Then Descrição do passo 3
Uma coisa importante, é que normalmente por questão de boas práticas só utilizamos uma de cada keyword, com exceção do And, visto que mais de um fluxo de Given, When e Then poderia simplesmente ser transformado em um outro teste.
step_definitions
É o diretório que vai armazenar todos os arquivos relativos à execução de cada passo a passo dos cenários escritos para cada feature.
Aqui é onde aquelas linhas de cada feature deixam de ser abstratas, e passam a ser mais claras com relação a como o código irá interagir com a interface web do projeto, basicamente só é necessário ligar o código de execução à Keyword+passo descrito para fazer com que os arquivos .features possam ser executados normalmente, a estrutura de um step é a seguinte:
Keyword(‘Descrição do passo’), async () => {
await Código_a_ser_executado;
…
});
Nossas contribuições
Nossas contribuições para disciplina foram:
- Reestruturar a forma de testes automatizados: o framework de testes automatizados que foi utilizado antes era o Cypress, decidimos utilizar o CodeceptJS pois acreditamos que é um framework bem mais simples de utilizar e seria bem amigável para novos contribuidores, basicamente o próprio código já serve como documentação.
- Escrever 28 casos de teste:
- Casos que passam: 20
- Casos que falham : 8
(Link para video mostrando o CodeceptJS em ação)