34
Desenvolvimento orientado a testes Denis Ferrari

TDD (Resumo)

Embed Size (px)

DESCRIPTION

Arquivo que uso para apresentar o TDD e Agile.

Citation preview

Page 1: TDD (Resumo)

Desenvolvimento orientado a testes

Denis Ferrari

Page 2: TDD (Resumo)

Sobre Denis Ferrari

Graduando em Sistemas de informação pela FAESA;

Arquiteto de software; Ministra palestras e treinamentos; Consultor de negócios; MCP, MCTS (Web Applications e Distributed

Applications), MCPD (Web Applications); Escreve artigos para os portais Imasters, Linha de

código e os disponibiliza também em seu blog. 9 anos de experiência no mercado de TI capixaba

atuando como Instrutor, Web Master, Desenvolvedor Sênior e Gerente de Projetos;

Page 3: TDD (Resumo)

Objetivos da palestra

Apresentar a metodologia ágil e seus valores.

Apresentar o desenvolvimento orientado a testes como uma alternativa ao desenvolvimento tradicional.

Page 4: TDD (Resumo)

Metodologia Ágil

Page 5: TDD (Resumo)

Metodologia Ágil

Desenvolvimento ágil de software (do inglês Agile software development) ou Método ágil é um conjunto de metodologias de desenvolvimento de software. O desenvolvimento ágil, tal como qualquer metodologia de software, providencia uma estrutura conceitual para reger projetos de engenharia de software.

http://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software

Page 6: TDD (Resumo)

Histórico

Começou em um encontro em Fevereiro de 2001, Utah, USA. com os seguintes representantes: Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, e outros;

O objetivo do encontro foi discutir alternativas ao rigoroso processo de documentação necessário para o processo de desenvolvimento de software;

Deu origem ao "Manifesto Ágil" assinado pelos dezessete participantes do encontro.

Page 7: TDD (Resumo)

DEFINIÇÃO:

Movimento iniciado por programadores experientes e

consultores

em desenvolvimento de software.

PRINCÍPIOS:

Indivíduos e interações X processos e ferramentas;

Software funcional X documentação abrangente;

Colaboração com o cliente X negociação de contratos;

Adaptação a mudanças X seguir plano inicial.

http://agilemanifesto.org/

Conceitos

Page 8: TDD (Resumo)

Assinaram o manifesto:

Kent Beck,

Mike Beedle,

Arie van Bennekum,

Alistair Cockburn,Ward Cunningham,

Martin Fowler,

James Grenning,

Jim Highsmith,

Andrew Hunt,

Roland Jeffries,

Jon Kern,

Brian Marick,

Robert C. Martin,

Steve Mellor,

Ken Schwaber,

Jeff Sutherland;

Dave Thomas.

Page 9: TDD (Resumo)

TDD

Page 10: TDD (Resumo)

TDD é uma técnica de desenvolvimento de software cujo processo é formado por pequenas iterações para o desenvolvimento de uma nova funcionalidade, começando pela implementação de um caso de teste, depois pelo código necessário para fazer o teste passar, e finalmente pela refatoração do código visando melhor acomodar as mudanças feitas.

Não é um método para testar software, mas para construir software.

TDD vem do conceito de “test-first programming” do XP (Extreme Programming), mas acabou ganhando tanto interesse, que hoje tem sido adotado independente do XP e das técnicas de programação ágil;

Introdução ao TDD (1/2)

Page 11: TDD (Resumo)

Objetivo do TDD: código limpo que funciona

“Mantra” do TDD: vermelho-verde-refatorar Codifique o teste; Faça ele compilar e executar (não deve

passar - vermelho); Implemente o requisito e faça o teste

passar (verde); Refatore o código;

Introdução ao TDD (2/2)

Page 12: TDD (Resumo)

Garante a existência de testes unitários completos e atualizados, que:

Eliminam o medo de alterarmos alguma coisa que funciona (testada manualmente), e acabarmos introduzindo algum problema;

Nos permite utilizar refatoração (substituir uma implementação por outra equivalente) de forma muito mais agressiva devido à facilidade dos testes verificarem o resultado.

Diminui a quantidade de erros por linha de código (código-fonte de mais qualidade)

Testes unitários servem como especificação de como os componentes do sistema funcionam;

Nos leva a produzir componentes de software mais desacoplados, para garantir o isolamento dos testes, o que acaba favorecendo o projeto do sistema.

Principais Benefícios do TDD

Page 13: TDD (Resumo)

Testes de Unidade; Testes de Integração; Testes de Sistema; Testes de Integração de Sistema; Testes de Aceitação;

Tipos de Testes

Page 14: TDD (Resumo)

A Metodologia TDD é conduzida através dos “testes do programador”.

Frequentemente esses testes são chamados de “teste de unidade”, mas esse nem sempre é o caso (pode ser teste de integração).

É importante destacar que não se trata dos testes de sistema (caixa preta) nem os de aceitação (feitos pelo usuário final)

Tipos de Testes

Page 15: TDD (Resumo)

A “Espiral da Morte” do Teste O ciclo mortal do “estou sem tempo

para testar”:

Page 16: TDD (Resumo)

1. Construa testes isolados uns dos outros Um caso de teste não deve depender do

sucesso de outro para funcionar; Deve ser possível executar um caso de testes

isoladamente, sem executar nenhum outro; 2. Comece definindo uma “Test List”

De modo geral para uma mesma classe ou método a ser testado, existirão diferentes casos de teste. Liste-os primeiro (brain-storm);

Provavelmente ao longo do desenvolvimento você adicionará novos casos de teste à lista;

Princípios

Page 17: TDD (Resumo)

Mas o que testamos? Fluxos Condicionais (IFs, Switches, etc.) Polimorfismos Loops Operações Etc..

Princípios

Page 18: TDD (Resumo)

Exemplo de “Lista de Testes” para o caso de uso “Realizar Transferência Bancária”:▪ Realizar uma transferência normal (bem

sucedida);▪ Tentar transferir uma quantidade superior ao

saldo da conta de origem;▪ Verificar atomicidade no caso de falha de

sistema antes de concluir a operação;▪ Conta de origem inativa;▪ Conta de destino inativa;▪ Valor transferido menor que zero;

Princípios

Page 19: TDD (Resumo)

Exemplo de “Lista de Testes” para o caso de uso “Matricular Aluno em Disciplina”:▪ Matricular com sucesso;▪ Tentar matricular sem atender disciplinas pré-requisito;▪ Tentar matricular sem atender pré-requisito de crédito;▪ Tentar matricular com conflito de horário;▪ Tentar matricular sem vaga;▪ Tentar matricular em disciplina já cumprida;▪ Tentar matricular em disciplina que já está matriculada

(outra turma);▪ Tentar matricular em disciplina que já está matriculada

(mesma turma);

Princípios

Page 20: TDD (Resumo)

3. Primeiro o Teste Oportunidade para pensar no design (projeto) das

classes Controlar o escopo do que será implementado –

somente o necessário para atender o teste corrente. 4. Primeiro a Assertiva

É melhor pensarmos no que significa o sucesso do caso de teste antes de pensarmos no restante:

▪ Vou precisar de criar um novo método?▪ Em qual classe?▪ Qual será o nome dele e seus parâmetros?

“Primeiro a assertiva” está para o caso de teste assim como “Primeiro o teste” está para o caso de uso;

Princípios

Page 21: TDD (Resumo)

Exemplo: Testar o envio da string “Teste” através de um socket.

Princípios

public void TestarComunicacaoSocket() {

Assert.IsTrue(readerSocket.Close()); Assert.AreEqual(“Qualidata”, buf); }

public void TestarComunicacaoSocket() { string buf = reader.Contents();

Assert.IsTrue(readerSocket.Close()); Assert.AreEqual(“Qualidata”, buf); }

public void TestarComunicacaoSocket() { Socket readerSocket = new Socket(“localhost”, 8080); string buf = reader.Contents();

Assert.IsTrue(readerSocket.Close()); Assert.AreEqual(“Qualidata”, buf); }

public void TestarComunicacaoSocket() { Server server = new Server(8080, “Teste”); Socket readerSocket = new Socket(“localhost”, 8080); string buf = reader.Contents();

Assert.IsTrue(readerSocket.Close()); Assert.AreEqual(“Qualidata”, buf); }

Page 22: TDD (Resumo)

5. Dados para Teste Não escolha números mágicos se eles não tiverem

um significado específico no teste. Por exemplo, se não faz diferença utilizar “1”, “2” ou “1365”, preferia “1”.

Evite passar o mesmo valor para diferentes parâmetros. Por exemplo, para testar um método Operacao(int x, int y), não utilize Operacao(2,2), pois “Operacao” pode inverter “x” e “y” e o teste ainda assim passar. Prefira, por exemplo, Operacao(2,3).

Dê preferência a dados do mundo real, especialmente quando você tem algum sistema legado com dados que podem ser aproveitados

Princípios

Page 23: TDD (Resumo)

6. Dados com Significado Evidente Lembre que está escrevendo um teste

para alguém ler, e não somente para ser executado pelo computador.

Tente escrever na assertiva expressões que não só representem o valor final esperado, mas o que eles significam.

Exemplo:

Princípios

[Test] public void Testar_Fatorial_8() { Assert.AreEqual(40320, Matematica.Fatorial(8)); }

[Test] public void Testar_Fatorial_8() { Assert.AreEqual(8 * 7 * 6 * 5 * 4 * 3 * 2, Matematica.Fatorial(8)); }

Page 24: TDD (Resumo)

Trata sobre quando escrever, onde escrever e quando parar de escrever testes.

Qual o próximo teste da lista a implementar? Escolha um teste que você esteja confiante que pode

implementá-lo facilmente; Não comece pelo teste mais realístico (completo), pois

você será forçado a implementar um monte de coisas para atender o teste.

Siga na direção “mais conhecidos” para “pouco conhecidos”

Cada iteração “red/green/refactor” deve levar apenas alguns minutos.

Exercício: Se você estiver construindo uma lista encadeada, qual seria seu primeiro caso de teste?

“Red Bar Patterns”

Page 25: TDD (Resumo)

Testes de Estudo Devemos escrever testes para componentes

ou bibliotecas de terceiros que, supostamente, funcionam?

Sim. Para estudar e documentar seu uso. Esse é uma forma de assegurar-se sobre

como utilizar tal biblioteca de forma a obter os resultados esperados e documentar seu uso (considerando especificamente suas necessidades, e não todos os recursos da biblioteca).

“Red Bar Patterns”

Page 26: TDD (Resumo)

Testes de Outras Funcionalidades Sempre que uma discussão desviar do

assunto principal e entrar em outras questões, essa pode ser uma hora de adicionar novos casos de teste à sua lista (para a funcionalidade em questão) e voltar para o assunto principal.

“Red Bar Patterns”

Page 27: TDD (Resumo)

Defeitos Reportados Sempre que um defeito é reportado nossa primeira ação

deve ser escrever um caso de teste que reproduza o problema. Se isso for feito certamente o problema será resolvido.

Testes de Regressão Consiste em testar novamente uma funcionalidade que foi

implementada e testada anteriormente; Teoricamente, após qualquer alteração no sistema, todo o

sistema deveria ser testado para garantir que essa alteração não tenha introduzido algum efeito colateral indesejável.

Uma boa prática é executar testes de regressão de todo o sistema, todos os dias, à noite, e reportar os problemas encontrados para a equipe. Existem softwares para gerenciar isso.

“Red Bar Patterns”

Page 28: TDD (Resumo)

Técnicas mais detalhadas sobre como escrever testes. Subdividir Testes

Quando um teste ficou grande demais e você está demorando muito para conseguir implementá-lo (mais de 10 min já deve te encomodar), pode ser melhor dividir o teste em testes menores até conseguir fazer o teste maior passar.

Mock Objects Como testar objetos que dependem de recursos externos

custosos ou complexos, como bancos de dados e webservices, por exemplo?

Crie uma versão falsa ou simulada do objeto (“fake”) que retorne valores constantes.

Referência: www.mockobjects.com Ferramentas para .NET: NMock e Rhino Mocks.

“Testing Patterns”

Page 29: TDD (Resumo)

Uma vez que você tenha um teste vermelho, busque torná-lo verde o quanto antes.

Use os padrões que serão discutidos para conseguir isso rapidamente, mesmo que o resultado seja algo que você não aceita conviver nem por uma hora.

“Green Bar Patterns”

Page 30: TDD (Resumo)

“Fake it ‘til you make it” (simule até construir realmente) Por exemplo, qual é a forma mais

simples de implementar o código abaixo?

A forma mas direta seria:

“Green Bar Patterns”

public void TestarSoma() { Assert.AreEqual(5, Somar(2,3)); }

public int Somar(int x, int y) { return 5; }

public void TestarSoma() { Assert.AreEqual(5, Somar(2,3)); }

Page 31: TDD (Resumo)

Triangulação Quando você tem dois ou mais testes, você precisa de

uma implementação que atenda a todos simultaneamente.

Agora a solução trivial (constante) não atende mais, e somos forçados e implementar algo mais abrangente.

É claro que esse exemplo é apenas ilustrativo. Se você já tem uma implementação correta óbvia, então implemente. Senão, “fake it”.

“Green Bar Patterns”

Página 31

public void TestarSoma() { Assert.AreEqual(5, Somar(2,3)); Assert.AreEqual(7, Somar(3,4)); }

Page 32: TDD (Resumo)

Implementação Óbvia Se você consegue implementar algo

diretamente, então implemente. Para que utilizar “fake” ou triangulação?

Mas quando você achar que sabe implementar e se deparar com uma barra vermelha? Depois você descobre, errei aqui, e aí outra barra vermelha! Talvez seja hora de dividir o problema em problemas menores.

Acreditar que você sempre vai conseguir acertar e escrever o código mais simples para o problema diretamente é exigir de você perfeição.

“Testing Patterns”

Page 33: TDD (Resumo)
Page 34: TDD (Resumo)

Informações para contato

E-mail/MSN: [email protected] Gtalk: [email protected] Site: www.denisferrari.com Blog:

desenvolvimento.denisferrari.com Twitter: @denisferrari