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


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


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


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


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/

UnP Eng. Software - Aula 27

Technology

Transcript of UnP Eng. Software - Aula 27