Para aferir a qualidade de um produto ou serviço, você o testa, correto? Mas e se você pudesse testá-lo antes mesmo dele existir? Parece impossível mas, conceitualmente falando, é exatamente o que preconiza a abordagem de desenvolvimento orientado a testes.

O cenário econômico atual, de centralidade das empresas de tecnologia, faz com que elas ditem tendências, inclusive sobre como se dá a gestão da qualidade em produtos e serviços. E o paradigma corrente da indústria de software é o da melhoria contínua.

Para que programas sejam frequentemente incrementados, são aplicadas práticas de qualidade desde a fase conceitual e, principalmente, até o ambiente produtivo. Os sistemas são constantemente monitorados e passamos a exercitar a qualidade de forma ininterrupta, adotando assim a estratégia de qualidade como serviço.

Em outras palavras, a qualidade das aplicações passa necessariamente por validações perenes e massivas em todas as etapas do desenvolvimento. Para que cada pequeno fragmento de código já seja criado atendendo a requisitos de qualidade, usa-se a abordagem de desenvolvimento orientado a testes, uma das mais praticadas no mercado para aumentar a confiabilidade do sistema em todos os estágios da produção e reduzir o volume de esforço de inspeção na fase de lançamento. Siga com a gente neste texto para conhecer melhor essa prática!

Princípios e procedimentos

A abordagem de desenvolvimento orientado a testes – mundialmente conhecida pela sigla TDD, que significa Test-Driven Development – foi desenvolvida pelo engenheiro de software Kent Back na virada do século XX para o XXI. De acordo com o próprio Kent em seu livro cujo título dá nome à abordagem, o TDD é uma forma de desenvolver código direcionado ao teste automatizado pelo qual aquele código passará. Caso o bloco não seja “aprovado”, daí novo código é produzido. É uma abordagem que visa gerar código limpo e que funciona.

Como está na definição da própria abordagem, a TDD exige testes unitários e automatizados para desenvolvimento de código e, consequentemente, aplicações. Ou seja, a inspeção já é realizada em conjunto ao desenvolvimento, detectando falhas precocemente e propagando uma “rede de segurança” a partir dos pequenos fragmentos da aplicação. Assim, evitam-se que erros escalem para módulos maiores do sistema.

Em uma rotina clássica de desenvolvimento orientado a testes, o programador segue cinco passos:

1. Escreve um teste que vai falhar → Escreve-se um teste para uma funcionalidade que ainda não existe. Como não há código para ser testado, ele vai falhar. Essa etapa funciona apenas a “especificação de requisitos” do código que está para ser construído
2. Rode o teste → Execute o teste e veja-o falhar. Primeiro para verificar se o próprio teste foi escrito corretamente e segundo para checar se ele está realmente testando o que foi previsto para ser inspecionado
3. Codifique o mínimo → Escreve-se o primeiro bloco de código, mas apenas o mínimo necessário para passar no teste
4. Rode novamente o teste → Execute novamente o teste para agora vê-lo passar. É a confirmação que tanto inspeção quanto código foram bem-feitos
5. Refatoração de código → Com código e teste “prontos”, o desenvolvedor deve analisar o código buscando melhorar design, leitura e performance caso seja necessário. O ponto fundamental a ser observado é que a refatoração não deve quebrar os testes já escritos.

Esses cinco passos são resumidos no princípio mais fundamental da abordagem: red/green/refactor, que pode ser livremente traduzido por “vermelho/verde/refatore”. Os passos um e dois são o “sinal vermelho”: o teste vai falhar. Os três e quatro são o “verde”: código aprovado. O passo cinco é a refatoração, visando aumentar ainda mais a qualidade do código.

Desenvolvimento orientado a testes: como ele ajuda a criar aplicações melhores

A partir dos princípios e procedimentos da TDD, já fica evidente um benefício trazido pela abordagem, quando comparada a outras: a documentação. Quando é aplicado o desenvolvimento orientado a testes, não só a inspeção ocorre concomitante ao desenvolvimento, mas também parte da documentação da verificação de qualidade, uma vez que testes e blocos de código são escritos quase simultaneamente.

Aplicações desenvolvidas sob TDD apresentam densidade de defeitos sensivelmente menor do que as criadas usando outras metodologias. Isso porque a TDD garante o máximo de granularidade dos testes unitários e, em grande parte, o rigor, já que cada pequeno bloco de código é inspecionado.

Os benefícios trazidos pela abordagem estão documentados na literatura técnico-científica. Estudos de casos em projetos da Microsoft e da IBM mostraram que a densidade de defeitos pré-lançamento em sistemas que usaram TDD caiu entre 40 e 90%, se comparados a projetos similares que não usaram a abordagem. Em contrapartida, o tempo de desenvolvimento de código, propriamente dito, aumentou entre 15 e 35%.

Criada há aproximadamente 25 anos, a abordagem de desenvolvimento orientado a testes foi aprimorada para outras duas, também amplamente utilizadas no mercado: a de desenvolvimento orientado a comportamentos e a de desenvolvimento orientado a testes de aceitação. Ambos são métodos embasados conceitualmente pela TDD mas que não são orientados exclusivamente a testes.

A Inmetrics, desde suas origens, é pioneira em estratégias para aumentar a qualidade de sistemas críticos. Em nossa unidade de Experiência Digital, temos o foco de proteger a experiência do cliente final e a reputação da sua empresa sendo o advisor e parceiro em toda a sua jornada de qualidade.

Se você quer ter a tranquilidade de que suas aplicações não estejam minando a sua reputação e impactando seus negócios, clique aqui e faça contato! Nossa experiência em grandes empresas e o conhecimento em estratégias de qualidade estão à disposição – basta falar com um dos nossos especialistas, clicando aqui!