TEST-DRIVEN DEVELOPMENT
Corrigindo o problema certo da forma correta

HÉLIO MEDEIROS
Analista de Sistemas
SINFO - UFRN
Blog: http://heliomedeiros.com
Email: helio.cabralmedeiros@gmail.com

NOSSA AULA
• Parte 1 - Resolvendo o problema correto de forma correta
• Parte 2 - Qualidade em foco com TDD
• Parte 3 - Construindo da forma correta
• Parte 4 - Vermelho-Verde-Refatore
• Parte 5 - Construindo a coisa correta

1 Resolvendo o problema
correto da forma correta

TDD
“Apenas escreva algum código quando este for para concertar uma falha de
teste.” -Lasse Koskela
Isso é TDD em uma frase, primeiro escreva
um teste, para só então escrever o código
necessário para que o teste passe.
http://www.flickr.com/photos/kenstein/2948639488/

O DESAFIO
O objetivo do desenvolvimento de software é prover soluções às operações
e aos negócios das organizações, de forma que elas possam aumentar sua
eficiência reduzindo custos entre outros.
Mundo a fora existem excelentes empresas
que durante décadas amadureceram seus
processos e produzem muito código, mas
não conseguem mantê-los de forma
adequada com evoluções repetíveis.
http://www.flickr.com/photos/davidcotter/3170716354/

PROBLEMA COM CÓDIGO ?
Mesmo durante décadas de avanços na industria de
software a qualidade do código continua sendo um
problema.
“Defeitos criam custos indesejados fazendo com que os sistemas
fiquem instáveis, imprevisíveis ou inutilizáveis” -Lasse Koskela

DILEMA DOS DEFEITOS
Defeitos reduzem o valor dos softwares produzidos, em
vários casos criando mais estragos do que adicionando
valor . Naturalmente a forma encontrada para lidar com os
defeitos foi a execução de testes.
“Verificamos como o software funciona e tentamos quebrá-lo de
alguma maneira.” -Lasse Koskela

PESADELO DE MANUTENÇÃO
Um código pobre não possuem uma boa modelagem nem
um balanceamento entre responsabilidades, podendo em
muitos casos ter toneladas de trechos duplicados, e isso
pode ser um pesadelo para manter.
“Eu não vou mexer nisto. Isto pode nunca ter fim, e eu não farei
a menor idéia do que pode ser quebrado durante o caminho”

PROBLEMA COM REAIS
NECESSIDADES?
Mesmo com a crescente preocupação e evolução da
engenharia de requisitos, ainda existe muita mudança e mal
entendimento ocorrendo em projetos pelo mundo, clientes
com seus produtos inacabados ou impróprios.
“Requisitos mudam e suas validações também devem mudar,
porem o entendimento sobre as mudanças é mais claro ao
cliente e é por isso utilizamos testes de aceitação”

A SOLUÇÃO
TDD nos auxilia de duas formas quando pensamos em como corrigir estes
dois problemas, dos códigos pobres e pouco evolutivos e dos sistemas que
não refletem as reais necessidades, por meio de TESTES.
Qualidade externa
ATDD Qualidade interna
TDD

2 Qualidade em foco com
TDD

TIPOS DE QUALIDADE
Qualidade é definida perante o mercado atualmente de
várias maneiras:
•Qualidade como resultante da quantidade de defeitos
encontrados após a entrega, em produção;
•Qualidade como resultante da satisfação dos usuários em
relação a quantidade de preenchimento de expectativas e
necessidades.

CONTRIBUIÇÃO
TDD contribui para aumentar a qualidade do software em todos estes
aspectos com sua natureza orientada a qualidade e a boa modelagem.
Um dos grandes responsáveis pelos defeitos
encontrados em produção é a não
existência de uma verificação constante e
imparcial em todo o caminho da realização
de uma ação no nosso sistema. TDD nos
previne sobre impactos sofridos na
execução de ações do sistema após
alterações de código.
http://www.flickr.com/photos/radiofree/14243157/

CONTRIBUIÇÃO
TDD nos auxilia reduzindo o tempo necessários para corrigir os defeitos.
Como se sabe a corrigir problemas o quanto antes custa menos, TDD nos
auxilia a corrigi-los enquanto eles são introduzidos em nosso sistema.
“Realizando testes antes em pequenos passos nos temos como garantir
que não será necessário a utilização de modo debug. “ - Lasse Koskela

3 Construindo da forma
correta

CRESCENDO
“Apenas escreva algum código quando este for para concertar uma falha de
teste.” -Lasse Koskela
Para o TDD primeiro devemos escrever um
teste, para só então escrever o código
necessário para que o teste passe. Isto
parece ou soa estranho?
http://www.flickr.com/photos/kenstein/2948639488/

RE-APRENDENDO
Durante muitos anos aprendemos que a forma correta para se desenvolver
um sistema maduro e resistente deveríamos iniciar com uma solida
modelagem, em seguida implementá-la e por fim testar para encontrar os
defeitos que inserimos durante a codificação.
Ciclo tradicional de desenvolvimento
Modele Codifique Teste
Ciclo de desenvolvimento orientado a testes
Teste Codifique Modele

TESTE-CODIFIQUE-REFATORE
TDD inverte este ciclo. Mas isto soa um pouco estranho pois, a modelagem
como é feita no TDD ao final não se assemelha tanto com a aprendida
anteriomente; a modelagem no TDD foca no sentido de transformação do
modelo atual em um modelo melhor, por isso recebe o nome de refatoração.
Ciclo tradicional de desenvolvimento
Modele Codifique Teste
Ciclo de desenvolvimento orientado a testes
Teste Codifique REFATORE

4 Vermelho-Verde-Refatore

VERMELHO
Vermelho-verde-refatore é um mnemônico alternativo para o ciclo
construtivo do TDD.
Quando iniciamos escrevendo um teste, ele normalmente falha, pois ainda
não implementamos uma solução para o mesmo e isso é representado em
alguns ambientes de desenvolvimento na forma de uma barra vermelha.
Ciclo de desenvolvimento orientado a testes
Teste

VERMELHO-VERDE
O nosso segundo passo é sempre fazê-lo passar e assim implementamos as
funcionalidades que faltam para tal e recebemos em alguns ambientes de
desenvolvimento a representação de que tudo está correto por uma barra
verde.
Ciclo de desenvolvimento orientado a testes
Teste Codifique

VERMELHO-VERDE-REFATORE
O nosso terceiro e último estágio no ciclo de construção do TDD é
refatorar, para que nosso código e modelo fique cada vez melhor sem
duplicidade, mais simples de evoluir e entender. Caso não criemos nenhum
erro o ambiente continuará apresentando a barra verde.
Vermelho, Verde, Verde. Vermelho, Verde, Refatore.
Ciclo de desenvolvimento orientado a testes
Teste Codifique REFATORE

1º - ESCREVA UM TESTE
Primeiro escreva um teste que não passe. Quando escrevemos no primeiro
passo de nosso ciclo um teste, nos estamos realmente fazendo mais do que
apenas escrevendo-o, nos estamos tomando decisões, definindo as interfaces
de acesso as funcionalidades que iremos testar. Escrevendo testes antes, nós
nos forçamos a pensar em como queremos que nosso código seja utilizado.
“Pensar em como nosso código será usado é como montar um
quebra-cabeça. É difícil encontrar uma peça que você precisa
se você não sabe a que outras você vai precisar conecta-la.”
-Lasse Koskela
http://www.flickr.com/photos/mr_t_in_dc/3367120498/

1º - ESCREVA UM TESTE
Quando escrevemos no primeiro passo de nosso ciclo um teste, nos não
temos nenhuma escolha ao não ser fazer um código testável. A princípio não
existe código escrito que não seja testável. A modelagem do sistema não
trata apenas de estrutura; mas também sobre trabalhar as necessidade do
cliente, objetivando por meio de um questionamento explicito, sem
ambigüidades a real necessidade.
“Sem testes primeiro você estará desperdiçando dinheiro
desenvolvendo funcionalidades que não são realmente
necessárias, assim como desperdiçando dinheiro tendo que
lidar com correções sobre partes de código modelados
desnecessariamente .” -Lasse Koskela
http://www.flickr.com/photos/mr_t_in_dc/3367120498/

2º - ESCREVA SÓ O CÓDIGO
NECESSÁRIO
O segundo passo do ciclo é escrever apenas a quantidade suficiente de
código necessária para fazer o teste passar. Mas porque só a quantidade
mínima? O teste que escrevemos é um teste que falha, apontando um ponto
entre o que o software faz e o que ele precisa fazer. É um ponto simples e
curto que deve ser fechado em no máximo alguns minutos.
“Você não está apenas escrevendo um código qualquer, você
está satisfazendo um requisito explicito, sem ambigüidades
expresso pelo teste. Você está progredindo e continuamente
apresentando provas sobre isso .” -Lasse Koskela
http://www.flickr.com/photos/djpd/553827617/

3º - REFATORE
O passo final do ciclo é a refatoração, é aqui que você deve finalmente dar
um passo para trás e olhar a modelagem, analisando maneiras de fazê-lo
melhor.
“Você não está apenas escrevendo um código qualquer, você
está satisfazendo um requisito explicito, sem ambigüidades
expresso pelo teste. Você está progredindo e continuamente
apresentando provas sobre isso .” -Lasse Koskela
http://www.flickr.com/photos/thorinside/157777439/

5 Construindo a coisa
correta

ACCEPTANCE TDD
Acceptance TDD como o nome diz sugere alguma semelhança com o TDD
“comum”. Acceptance tests indicam aceitação de requisitos ou funcionalidades
enquanto a sua completeza.
“Quando todos os testes de aceitação de um requisitos ou
funcionalidade passam você sabe que o concluiu.”
-Lasse Koskela
http://www.flickr.com/photos/atelier_us/2659072696/

COLABORAÇÃO
Existem atualmente várias técnicas para se expressar requisitos que vão de
casos de uso, passando por user stories e ATDD está desacoplada de todas, o
objetivo principal é gerenciar requisitos atingindo a máxima colaboração
entre equipe de desenvolvimento e o cliente.
“A idéia fundamental para atingir o maior nível de
produtividade para todo o time é encorajar feedbacks rápidos
e comunicação efetiva face-a-face sobre software funcional
concreto ao invés da passagem de planos, especificação de
requisitos e reports de bugs entre clientes, testers, analistas de
negócios e desenvolvedores..”
-Lasse Koskela
http://www.flickr.com/photos/ivanwalsh/3646342408/