TDD - Test Driven Development

Prévia do material em texto

Nome do Curso
	Nota:
	Disciplina
	Engenharia de Software
	Data: 25 / 11 / 2017
	Docente
	Prof. Dr. Sérgio Luis Antonello
	Aluno
	Tiago dos Santos RA: 62179 
TDD – Test Driven Development
Introdução
O desenvolvimento orientado a testes (TDD) é uma metodologia que prioriza desenvolver os testes do sistema antes mesmo do código de produção. A cada código ou processo que será implantado deve haver um teste escrito, dessa forma todo o software será testado antes de ser implantado. Estes testes devem ser automatizados garantindo uma alta taxa de eficácia. A implantação do TDD consequentemente irá consumir mais tempo e demanda para o desenvolvedor, mas futuramente vai render menos erros ou manutenções e gastos com o software. Considerado o criador ou o 'descobridor' da técnica, Kent Beck, declarou em 2003 que TDD encoraja designs de código simples e inspira confiança.
Este método ágil mesmo sendo uma ferramenta que garante benefícios para o software ainda não é bem vista por grande parte de desenvolvedores e empresas de software pelo tempo e demanda de trabalho. Empresas de software que optam pelo TDD possuem uma taxa de bugs mínimos em seus softwares, e seus clientes não convivem com diversos erros mesmo tendo várias atualizações. Geralmente um software quando é criado exclusivamente para um cliente é mais acessível à utilização do TDD, desde que a empresa tenha essa demanda e consiga apresentar o projeto no prazo de acordo com que o cliente deseja, quando o sistema já é pronto as empresas variam bastante e esta metodologia pode ser ou não usada, nada impede que os testes sejam criados depois, por isso é algo que deve ser definido antes da implantação.
O TDD ajuda o desenvolvedor a garantir que os requisitos funcionem com o esperado e também o auxilia a perceber os problemas no código em suas implementações. Os testes automatizados que rodam em questão de segundos, são executados o tempo todo pelo desenvolvedor. Isso quer dizer que podemos executá-los o dia todo, muitas vezes por dia. Algo que sabemos ser impossível com testes manuais. Dessa maneira o desenvolvedor é notificado rapidamente caso haja algum erro no código, evitando problemas futuros com ó código.
Quem desenvolve com TDD sabe que é possível desenvolver com zero bugs ou algo próximo disso; e quando um bug é encontrado, o custo de manutenção é relativamente baixo com relação ao que já conhecemos no dia-dia.
Ao criar o teste antes de implementar a unidade, são reduzidos problemas como mal entendimento de requisitos ou interfaces, pois como criar um teste se eu não sei o que devo testar? É de extrema importância, para o desenvolvedor, o entendimento dos requisitos do cliente. Não adianta criar testes que não validem o código como um todo para reduzir o tempo, é necessário criar testes para o conjunto completo de unidades, só assim o TDD vai funcionar como deve, devendo fornecer uma cobertura completa aos testes.
O método de feedback apresentado pelo TDD também é muito relevante. Um desenvolvedor que testa seu código ao final de um projeto recebe um feedback completo, mas muito mais trabalhoso para efetuar correções e isso pode custar caro. Quando utiliza o teste automatizado a quantidade de feedbacks que recebe é o grande diferencial, pois a cada teste escrito ele implementa uma funcionalidade e o retorno é imediato. 
O desenvolvedor que faz testes manuais repete o mesmo teste várias vezes por dia. O desenvolvedor que o automatiza gasta seu tempo apenas uma vez. Na próxima vez, o teste será executado pela máquina em poucos milissegundos. Mais ainda, sempre que o desenvolvedor precisar testar novamente no futuro, ele o fará de maneira manual, gastando tempo. Já o desenvolvedor que tem testes automatizados, apenas executará sua bateria de testes. Ela durará pra sempre e poderá ser executada quantas vezes quiser. 
Método escolhido.
Para entender melhor o funcionamento desta metodologia ágil, é necessário dividir os processos em etapas:
 Planejar teste: o planejamento dos testes permite a identificação dos itens e funcionalidades que deverão ser testados, quem são os responsáveis e quais os riscos envolvidos. Ou seja, permite  definir o escopo, o custo e o prazo para as atividades de teste do projeto. Para a realização desta etapa, os responsáveis devem tomar como referência os requisitos e suas prioridades. Ainda na etapa de planejamento serão definidas estimativas, estratégias e técnicas de teste;
Projetar teste: com base nos requisitos que descrevem a funcionalidade a ser criada e no plano de teste, o testador deve projetar o teste imaginando tanto o fluxo normal de execução, quanto os fluxos de exceção. Para a realização de tal atividade o testador deve escrever o caso de teste e o roteiro de testes automáticos, detalhando as instruções contidas no projeto. Finalizado os documentos, deve-se submeter o teste para execução;
Executar teste: a execução do teste deve ser preferencialmente automática. Caso seja a primeira execução desse teste, necessariamente ele precisa falhar, uma vez que foi escrito antes da funcionalidade a ser implementada;
Codificar: é a etapa na qual a funcionalidade será implementada pelo(s) programador(es). A equipe de desenvolvimento deve estar focada nos requisitos da funcionalidade, e apenas o código necessário para o teste ser executado com sucesso deve ser produzido;
Refatorar código: nesse ponto o código produzido deve passar por uma "limpeza", com o objetivo de otimizar o código de maneira que seu comportamento não seja alterado (ex.: eliminando duplicações de código). Uma vez realizada a refatoração do código, os testes automáticos devem ser executados para garantir que esta não inseriu erros no código da funcionalidade.
	Para cada nova funcionalidade, o fluxo acima deve ser "re-executado". E mais, durante e após o desenvolvimento da nova funcionalidade, além do teste da mesma, todos os testes já existentes devem ser executados novamente. Fazendo isso, as equipes de desenvolvimento e de teste estarão garantindo que a implementação do novo recurso não gerará efeitos colaterais em outra parte do sistema. Durante a execução desse conjunto de testes, caso algum falhe inesperadamente, a equipe de desenvolvimento deve desfazer as alterações (até o ponto em que todos os testes voltem a ser executados com sucesso) e "re-implementar" a funcionalidade.
	Outro fator importante é seguir o modelo Test First: Rápidos - devem ser rápidos, pois testam apenas uma unidade; Independente - Testes unitários são isolados, testando individualmente as unidades e não sua integração; Repetitivo - Repetição nos testes, com resultados de comportamento constante; Auto-Verificação - deve verificar se passou ou se deu como falha o teste; Oportuno - O teste deve ser oportuno, sendo um teste por unidade.
	Um exemplo de uma ferramenta que utiliza o TDD é o JUnit, o mais popular framework de testes para Java. Ele facilita o desenvolvimento e execução de testes unitários em código Java. Ele Fornece uma completa API (conjunto de classes) para construir os testes e Aplicações gráficas e em modo console para executar os testes criados. As vantagens de utilizar esse framework são: JUnit pode verificar se cada unidade de código funciona da forma esperada; Facilita a criação, execução automática de testes e a apresentação dos resultados; É Orientado a Objeto; É free e pode ser baixado na internet.
	Com o Junit podemos criar testes para verificar funcionalidades de classes e seus métodos. Podemos automatizar também a execução de todos os testes de forma que quando for criada uma nova versão estável do sistema o framework execute todos os testes para garantir a integridade e estabilidade do sistema desenvolvido.
	O Junit trabalha basicamente com anotações (Annotations). Essas anotações indicam se um método é de teste ou não, se um método deve ser executado antes da classe e/ou depois da classe, as anotações indicam também se o teste deve ou não ser ignorado e sea classe em questão é uma suite de teste, ou seja, se a partir desta classe é disparada a execução das demais classes de teste, entre outras anotações menos utilizadas.
	Para utilizar JUnit é necessário ter um ambiente de desenvolvimento como o NetBeans, abaixo segue algumas imagens do software:
Conclusão
	O desenvolvedor que escreve testes automatizados gasta tempo com isso. Mas ele gasta tempo de maneira inteligente. Hoje, o desenvolvedor que faz teste manual também gasta muito tempo com testes, mas de maneira errada, improdutiva. Em médio prazo, esse desenvolvedor gastará mais tempo testando a mesma funcionalidade do que o que utilizou o TDD e os automatizou desde o começo. É tudo uma questão de pensar a médio prazo. Além de outras vantagens: colabora para o aumento da qualidade dos sistemas, o software cresce de forma ordenada e com qualidade de design e também se adapta com mais facilidade a mudanças.