No ambiente de desenvolvimento de grandes sistemas de software, um dos maiores desafios é a capacidade de identificar problemas na implementação do código. Para tal, temos atualmente áreas designadas com o propósito de realizar testes com o intuito de detectar tais problemas, como Quality Assurance, doravante QA, que possui como função a idealização e realização de casos de teste, nos quais, possíveis fraquezas na implementação de um software podem ser detectadas.
Comumente, profissionais da área de QA são de menor grau técnico que os desenvolvedores, o que cria um vácuo na comunicação dos casos de teste e na realização de tais casos. Além disso, a carga e a velocidade de produção de serviços e funcionalidades em um sistema de grande porte necessita constante avaliação e verificação de funcionalidades, o que torna a realização de tais casos de teste, de maneira manual, inviável para o estabelecimento de um patamar estável de qualidade no desenvolvimento ativo de software. Diante de tal realidade, surge a necessidade da automatização do processo de testes.
Porém, métodos contemporâneos de automatização de testes envolvem implementações que precisam ser realizadas por profissionais voltado à área técnica, consequentemente, temos um atraso na implementação dos testes, pois em cenários convencionais, temos uma equipe de QA que irá realizar testes manuais e projetar cenários de teste, e um time de desenvolvimento que irá implementar as funcionalidades ativamente e também terá que desenvolver os métodos automatizados de casos de teste, introduzindo um período de evolução ociosa para o time de desenvolvimento técnico, que se torna responsável por implementar dois sistemas em paralelo, o produto principal, que será objeto de análise do time de QA, e o sistema que irá realizar os testes automatizados (que pode também apresentar seus próprios problemas).
Logo, neste documento, será desenvolvida uma proposta de paradigma de testes, e uma ferramenta para tal, que permite que o time de QA não dependa do time de desenvolvimento para realizar testes automatizados, utilizando ferramentas como Gherkin para a descrição dos cenários de teste de maneira genérica, que evita a necessidade de implementação especificada da automatização de tais cenários.
Definimos Behaviour Driven Development, agora definido BDD, como a metodologia de desenvolvimento na qual os comportamentos esperados de um objeto a ser desenvolvido são descritos em linguagem natural, e posteriormente são implementados seguindo tais comportamentos descritos, de maneira que a descrição comportamental do software se torna o certificador de funcionamento do produto desenvolvido, ou seja, a descrição torna-se o caso de teste, feita a implementação.
Manualmente, isto significa que um time de QA irá descrever os comportamentos esperados do software a ser desenvolvido, o time de desenvolvimento irá implementar este de acordo com tais comportamentos, e por fim, o time de QA irá manualmente realizar testes que seguem os comportamentos descritos inicialmente.
Em um cenário em que os testes são realizados de maneira automatizada, o comportamento de um software é descrito pelo time de QA, implementado pelos desenvolvedores, e em seguida os desenvolvedores precisam adicionalmente implementar os testes que são descritos no cenário.
Ambos os casos envolvem um processo laborioso de verificação comportamental do software pós-implementação, o que pode acabar custando bastante tempo e recursos que poderiam estar sendo utilizados no desenvolvimento ativo e no aprimoramento de outros produtos, considerando ainda possíveis erros também na descrição dos comportamentos.
Portanto, é de valor intrínseco para o processo de desenvolvimento de softwares, que tais atrasos sejam reduzidos ao máximo possível, idealmente sendo eliminados completamente, sem que a verificação e validação do comportamento de um produto seja comprometida. Para tal, será proposto em seções subsequentes um modelo de testes de Web APIs que consiga reduzir a quantidade de passos no desenvolvimento, sem afetar negativamente a qualidade do software desenvolvido por fim.
Em análise neste documento, está a implementação de Web APIs especificamente, portanto os conceitos acima descritos e posteriormente dissertados terão apenas este escopo em mente, devido sua consistência comportamental. Porém não é descartada a possibilidade de aplicação deste conceito fora dos escopos das Web APIs, tais casos apenas não serão considerados no trabalho atual.
A princípio, definiremos o conceito de AGBDD formalmente, determinando o escopo do paradigma de testes que será implementado, nosso objetivo é alcançar um modelo em que os testes escritos não necessitem implementação específica (Autonomous), que estes sejam descritos utilizando aspectos genéricos de sua área de interesse (Generic), e que discorram em linguagem natural sobre o comportamento esperado de uma funcionalidade ou sistema (BDD). Feito isso, será desenvolvido um sistema seguindo este paradigma.
Para realizar tal processo, será implementado um sistema de software que tem como visão a facilitação do processo de desenvolvimento de Web APIs utilizando a linguagem Gherkin para a descrição de testes, e que será implementada em Python.
A linguagem Gherkin define uma coleção de cenários de testes de um determinado produto, um Feature File, que contém frases em linguagem natural descritivas do comportamento de uma Web API chamadas Statements.
Temos 3 tipos de statements:
Tais Statements podem ser arranjados em conjunto, e o conjunto de tais Statements formam um Scenario, que irá descrever um caso de teste, portanto, um Feature File é uma coleção de casos de teste referentes a um objeto em análise que será desenvolvido.
Utilizando a linguagem Gherkin, podemos então descrever o comportamento de uma API, desde o ambiente anterior em que ela se encontra, e os resultados que esperamos que ocorram ao chamá-la.
Também será utilizada a linguagem Python com a biblioteca Pytest-BDD como foco central, que utiliza de tais Feature Files para correlacionar Statements com métodos implementados que realizam os passos descritos. Desta maneira, conseguimos realizar os passos descritos em um Feature File de maneira automatizada, sem depender da interação direta do time de QA para executar cada passo manualmente.
Definidos os termos em que estamos trabalhando, a proposta deste TCC será desenvolver um paradigma genérico de testes para APIs, que de maneira automatizada, consegue realizar testes de cenários de qualquer API, independente de suas peculiaridades, que será apresentado por meio de uma ferramenta Web Open Source.
Tal paradigma, nomeado agora Autonomous Generic Behaviour Driven Development, apelidado AGBDD, é possível devido a nossa limitação para o tratamento de Web APIs, pois assim temos pré-definidos um ambiente em que o desenvolvimento de software ocorre, bem como o objetivo de tal desenvolvimento. Assim podemos analisar os aspectos gerais no desenvolvimento de uma API, e consequentemente, definir comportamentos genéricos que esperamos que todas APIs sigam. O elemento Open Source deste projeto também garante constante evolução, dada uma comunidade e condições materiais que a tornem suficientemente engajada na manutenção desta ferramenta, o que resultará em uma gradual expansão de cobertura de elementos minuciosos de certas aplicações, viabilizando uma escalabilidade em compatibilidade que não seria possível sem o elemento Open Source.
Sendo assim, o desenvolvimento de tal paradigma será feito de acordo com os seguintes passos:
Logo, a proposta deste TCC seria desenvolver uma ferramenta nova, acompanhada pela definição de um paradigma de testes focado em flexibilidade e redução dos passos do desenvolvimento.
Este projeto foi inicialmente apresentado durante meu estágio na empresa Opus Software, tendo sido aceito e entrado em desenvolvimento no final de 2022, desde então, grandes passos foram realizados desde a conceitualização do projeto. Atualmente nos encontramos nas retas finais de implementação ativa dos elementos abstratos do paradigma apresentado, estando agora no início do desenvolvimento do editor, e no final do desenvolvimento do gerador de testes. Também estamos realizando o desacoplamento de elementos relacionados a produtos internos da Opus que estavam presentes no produto como parte do desenvolvimento.
Portanto, o trajeto planejado para o TCC será o de finalização do desacoplamento de dados internos e estabelecimento do repositório Open Source nos próximos dois meses, e em Maio, iniciar a implementação dos elementos Web do projeto utilizando Flask.