UnP Eng. Software - Aula 27
-
Upload
helio-medeiros -
Category
Technology
-
view
733 -
download
1
description
Transcript of UnP Eng. Software - Aula 27
TEST-DRIVEN DEVELOPMENTCorrigindo o problema certo da forma correta
HÉLIO MEDEIROSAnalista de Sistemas
SINFO - UFRN
Blog: http://heliomedeiros.comEmail: [email protected]
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 interna
TDD
Qualidade externa
ATDD
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 sofr idos 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.
Modele Codifique Teste
Ciclo tradicional de desenvolvimento
Ciclo de desenvolvimento orientado a testes
ModeleCodifiqueTeste
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.
Modele Codifique Teste
Ciclo tradicional de desenvolvimento
Ciclo de desenvolvimento orientado a testes
REFATORECodifiqueTeste
TESTE-CODIFIQUE-REFATORE
4 Vermelho-Verde-Refatore
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.
VERMELHO
Ciclo de desenvolvimento orientado a testes
Teste
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.
VERMELHO-VERDE
Ciclo de desenvolvimento orientado a testes
CodifiqueTeste
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.
VERMELHO-VERDE-REFATORE
Ciclo de desenvolvimento orientado a testes
REFATORECodifiqueTeste
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.
1º - ESCREVA UM TESTE
“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/
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.
1º - ESCREVA UM TESTE
“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/
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.
2º - ESCREVA SÓ O CÓDIGO NECESSÁRIO
“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/
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.
3º - REFATORE
“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 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.
ACCEPTANCE TDD
“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/
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.
COLABORAÇÃO
“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/