Atenção: esse artigo tem um vídeo complementar. Clique e assista!
Trata de uma contextualização teórica e de uma aplicação prática do Test Driven Development (TDD), uma técnica que garante a qualidade do software em desenvolvimento e permite refatorar continuamente o código-fonte com a segurança que esse código continuará a funcionar corretamente.
Para que serve
Serve para que desenvolvedores melhorem o design de sua aplicação. Como TDD está vinculado ao código fonte, então a criação do teste antes do código permite ter certeza do funcionamento da porção de código durante a sua construção (obviamente se os testes forem bem escritos). Quando a porção de código passar em todos os testes, então é possível dizer que a feature em desenvolvimento está apta para refatorações.
Em que situação o tema é útil
No dia a dia do trabalho do desenvolvedor de software, seja na construção do código em um projeto novo, como na manutenção de um software existente. O TDD faz com que o código sob testes retorne os resultados definidos para a situação proposta, o que deixará o leitor tranquilo no momento que a feature sob sua responsabilidade passar em todos os testes, pois a mesma estará pronta.
Test Driven Development
Nesse artigo será apresentada uma breve teoria acerca do tema TDD – Test Driven Development / Desenvolvimento dirigido por testes, bem como uma prática conhecida por Coding Dojo, convertido em uma versão escrita, como um meio para exercitarmos a prática do TDD de uma forma disciplinada e ilustrativa.
O mundo do desenvolvimento de software vem passando por transformações recorrentes desde sua adoção no meio corporativo, iniciado na década de 1960. A cada grande problema enfrentado no desenvolvimento de sistemas, surgia uma nova abordagem de solucionar esses problemas, gerando assim novos paradigmas capazes de fazer frente aos desafios vindouros.
Um grande dilema da indústria do software consiste na seguinte questão: “Como entregar software de qualidade dentro do escopo, prazo e custo acordados?”. A busca pela resposta a essa questão foi a força motriz que originou diversas abordagens, como a criação do CMM, com a posterior evolução para o CMMi, pelo Software Engineering Institute, da Carnegie Mellon University, a criação do Unified Process, e seu posterior refinamento pela Rational, originando o Rational Unified Process. No Brasil, temos o exemplo do MPS-BR, como uma iniciativa que visa qualificar a indústria de software.
O fato latente na indústria de software mundial é que a questão anteriormente proposta ainda está em vias de ser solucionada. Nesse aspecto, precisamos ressaltar que softwares ainda são entregues fora do prazo, com escopo diferente do combinado originalmente, com custo diferente (entenda-se superior) do contratado e com qualidade abaixo do esperado. Vamos à seguinte analogia: Como uma pessoa se sentiria se, precisando submeter-se a uma cirurgia de, por exemplo, apêndice, descobrisse que sua perna fora amputada?
Nesse artigo, proponho desenvolver uma abordagem ligada ao Test Driven Development, corroborando com os demais colegas que já escreveram sobre o tema em edições anteriores, através do desenvolvimento de um software utilizando essa técnica. Adicionarei a este artigo “pitadas” de engenharia de software, pois é necessário entendermos que, através dos nossos softwares, entregamos soluções de negócio aos nossos clientes que visam sanar problemas que os mesmos possuem em suas organizações.
A fim de atingir o objetivo proposto de maneira holística, apresentaremos as origens do Test Driven Development.
Algumas considerações
Uma área que está em crescimento, e auxilia muito na fase de descoberta, com foco em entrega de valor ao cliente, é a área de análise de negócios. A análise de negócios consiste num conjunto de boas práticas em processos que visam entendermos como uma organização funciona no âmbito de sua cultura, visão e missão, o que essa empresa produz, como ela produz, bem como nos permite indicar e validar ações que levem a soluções efetivas de problemas de negócios que essa empresa possua. Ademais, permite dar condições para manter o foco em atingir os objetivos de negócios e oportunidades que surjam para a empresa. Conforme a necessidade, a partir do momento em que aplicarmos técnicas previstas na Análise de Negócios, na fase de descoberta, a definição dos testes será mais assertiva, e TDD será um complemento para a entrega do software ao cliente final. Na seção Links é possível encontrar o site do BABOK – Business Analysis Body of Knowledge, principal guia de análise de negócios, publicado e mantido pelo IIBA – International Institute of Business Analysis, Instituto Internacional de Análise de Negócios.
Hoje já se fala em torno de ATDD – Acceptance Test Driven Development. É interessante nesse ponto recordar as seguintes delimitações:
· Teste de unidade: São os testes executados na menor porção de software, ou seja, a classe;
· Testes de integração: São os testes que verificam o correto funcionamento dos módulos interconectados do sistema, como um grupo;
· Testes de aceitação: São os testes executados sob a perspectiva do usuário.
Existem ferramentas, como o Selenium e o Cucumber, que permitem automatizar os testes de aceitação, ou seja, as ações dos usuários são automatizadas a fim de serem executados diversas vezes. Então, a partir dos critérios de aceitação, podemos criar ações que permitem avaliar as respostas do software às requisições do usuário, independentemente da tecnologia empregada para desenvolver a solução. Portanto, o software será considerado pronto – a definition of done, ou definição de pronto – quando o mesmo passar por todos os testes de unidade e de aceitação.
...
