TEST-DRIVEN DEVELOPMENT
   Corrigindo o problema certo da forma correta
HÉLIO MEDEIROS
                       Analista de Sistemas
                         SINFO - UFRN




Blog: http://heliomed...
NOSSA AULA

• Parte   1 - Resolvendo o problema correto de forma correta

• Parte   2 - Qualidade em foco com TDD

• Parte...
1   Resolvendo o problema
    correto da forma correta
TDD

“Apenas escreva algum código quando este for para concertar uma falha de
                         teste.” -Lasse Kosk...
O DESAFIO

O objetivo do desenvolvimento de software é prover soluções às operações
e aos negócios das organizações, de fo...
PROBLEMA COM CÓDIGO ?

     Mesmo durante décadas de avanços na industria de
     software a qualidade do código continua ...
DILEMA DOS DEFEITOS

    Defeitos reduzem o valor dos softwares produzidos, em
    vários casos criando mais estragos do q...
PESADELO DE MANUTENÇÃO

    Um código pobre não possuem uma boa modelagem nem
    um balanceamento entre responsabilidades...
PROBLEMA COM REAIS
      NECESSIDADES?
  Mesmo com a crescente preocupação e evolução da
  engenharia de requisitos, ainda...
A SOLUÇÃO

TDD nos auxilia de duas formas quando pensamos em como corrigir estes
dois problemas, dos códigos pobres e pouc...
2   Qualidade em foco com
    TDD
TIPOS DE QUALIDADE

 Qualidade é definida perante o mercado atualmente de
 várias maneiras:

•Qualidade como resultante da ...
CONTRIBUIÇÃO

TDD contribui para aumentar a qualidade do software em todos estes
aspectos com sua natureza orientada a qua...
CONTRIBUIÇÃO
TDD nos auxilia reduzindo o tempo necessários para corrigir os defeitos.
Como se sabe a corrigir problemas o ...
3   Construindo da forma
    correta
CRESCENDO

“Apenas escreva algum código quando este for para concertar uma falha de
                         teste.” -Lass...
RE-APRENDENDO
Durante muitos anos aprendemos que a forma correta para se desenvolver
um sistema maduro e resistente deverí...
TESTE-CODIFIQUE-REFATORE
TDD inverte este ciclo. Mas isto soa um pouco estranho pois, a modelagem
como é feita no TDD ao fi...
4   Vermelho-Verde-Refatore
VERMELHO
Vermelho-verde-refatore é um mnemônico alternativo para o ciclo
construtivo do TDD.

Quando iniciamos escrevendo ...
VERMELHO-VERDE
O nosso segundo passo é sempre fazê-lo passar e assim implementamos as
funcionalidades que faltam para tal ...
VERMELHO-VERDE-REFATORE
O nosso terceiro e último estágio no ciclo de construção do TDD é
refatorar, para que nosso código...
1º - ESCREVA UM TESTE
Primeiro escreva um teste que não passe. Quando escrevemos no primeiro
passo de nosso ciclo um teste...
1º - ESCREVA UM TESTE
Quando escrevemos no primeiro passo de nosso ciclo um teste, nos não
temos nenhuma escolha ao não se...
2º - ESCREVA SÓ O CÓDIGO
         NECESSÁRIO
O segundo passo do ciclo é escrever apenas a quantidade suficiente de
código n...
3º - REFATORE
O passo final do ciclo é a refatoração, é aqui que você deve finalmente dar
um passo para trás e olhar a model...
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ç...
COLABORAÇÃO
Existem atualmente várias técnicas para se expressar requisitos que vão de
casos de uso, passando por user sto...
Próximos SlideShares
Carregando em…5
×

UnP Eng. Software - Aula 27

871 visualizações

Publicada em

Segunda aula sobre testes, na qual é apresentada a turma a regra fundamental de desenvolvimento orientado a testes, o desafio existente no desenvolvimento e manutenção de software e como podemos manter a qualidade interna e externa de nosso código com TDD e ATDD. Por fim é apresentado o ciclo de desenvolvimento com TDD e como conseguimos software melhor e mais condizente com as necessidades de nosso clientes com ATDD.

Publicada em: Tecnologia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
871
No SlideShare
0
A partir de incorporações
0
Número de incorporações
4
Ações
Compartilhamentos
0
Downloads
19
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

UnP Eng. Software - Aula 27

  1. 1. TEST-DRIVEN DEVELOPMENT Corrigindo o problema certo da forma correta
  2. 2. HÉLIO MEDEIROS Analista de Sistemas SINFO - UFRN Blog: http://heliomedeiros.com Email: helio.cabralmedeiros@gmail.com
  3. 3. 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
  4. 4. 1 Resolvendo o problema correto da forma correta
  5. 5. 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/
  6. 6. 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/
  7. 7. 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
  8. 8. 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
  9. 9. 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”
  10. 10. 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”
  11. 11. 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
  12. 12. 2 Qualidade em foco com TDD
  13. 13. 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.
  14. 14. 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/
  15. 15. 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
  16. 16. 3 Construindo da forma correta
  17. 17. 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/
  18. 18. 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
  19. 19. 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
  20. 20. 4 Vermelho-Verde-Refatore
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. 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/
  25. 25. 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/
  26. 26. 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/
  27. 27. 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/
  28. 28. 5 Construindo a coisa correta
  29. 29. 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/
  30. 30. 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/

×