SlideShare uma empresa Scribd logo
Desenvolvimentoorientado a testes Denis Ferrari
SobreDenis Ferrari GraduandoemSistemas de informaçãopelaFAESA; Arquiteto de software; Ministrapalestras e treinamentos; Consultor de negócios; MCP, MCTS (Web Applications e Distributed Applications), MCPD (Web Applications); EscreveartigosparaosportaisImasters, Linha de código e osdisponibilizatambémemseu blog. 9 anos de experiência no mercado de TI capixabaatuandocomoInstrutor, Web Master, DesenvolvedorSênior e Gerente de Projetos;
Objetivosdapalestra Apresentar a metodologiaágile seusvalores. Apresentar o desenvolvimentoorientado a testescomoumaalternativaaodesenvolvimentotradicional.
MetodologiaÁgil
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
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-DrivenDevelopment, 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.
Conceitos DEFINIÇÃO:Movimento iniciado por programadores experientes e consultoresem 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/
Assinaram o manifesto: Kent Beck,  Mike Beedle,  Arie van Bennekum,  AlistairCockburn,WardCunningham,  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.
TDD
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)
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)
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
Testes de Unidade; Testes de Integração; Testes de Sistema; Testes de Integração de Sistema; Testes de Aceitação; Tipos de Testes
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
A “Espiral da Morte” do Teste O ciclo mortal do “estou sem tempo para testar”:
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 “TestList” 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
Mas o que testamos? Fluxos Condicionais (IFs, Switches, etc.) Polimorfismos Loops Operações Etc.. Princípios
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
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
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
Exemplo: Testar o envio da string “Teste” através de um socket. Princípios publicvoidTestarComunicacaoSocket()         { Assert.IsTrue(readerSocket.Close()); Assert.AreEqual(“Qualidata”, buf);         } publicvoidTestarComunicacaoSocket()         {                 string buf = reader.Contents(); Assert.IsTrue(readerSocket.Close()); Assert.AreEqual(“Qualidata”, buf);         } publicvoidTestarComunicacaoSocket()         { SocketreaderSocket = newSocket(“localhost”, 8080);                 string buf = reader.Contents(); Assert.IsTrue(readerSocket.Close()); Assert.AreEqual(“Qualidata”, buf);         } publicvoidTestarComunicacaoSocket()         { Serverserver = newServer(8080, “Teste”); SocketreaderSocket = newSocket(“localhost”, 8080);                 string buf = reader.Contents(); Assert.IsTrue(readerSocket.Close()); Assert.AreEqual(“Qualidata”, buf);         }
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
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] publicvoid Testar_Fatorial_8()         { Assert.AreEqual(40320, Matematica.Fatorial(8));         }  [Test] publicvoid Testar_Fatorial_8()         { Assert.AreEqual(8 * 7 * 6 * 5 * 4 * 3 * 2, Matematica.Fatorial(8));         }
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”
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”
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”
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”
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. MockObjects 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 RhinoMocks. “TestingPatterns”
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”
“Fake it ‘til youmake 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” publicvoidTestarSoma() { Assert.AreEqual(5, Somar(2,3));      } publicvoidTestarSoma() { Assert.AreEqual(5, Somar(2,3));      } publicint Somar(int x, int y) { return 5;      }
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 publicvoidTestarSoma()       { Assert.AreEqual(5, Somar(2,3)); Assert.AreEqual(7, Somar(3,4));      }
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. “TestingPatterns”
Informaçõesparacontato E-mail/MSN: denisferrari@live.com Gtalk: denis.sisinf@gmail.com Site: www.denisferrari.com Blog: desenvolvimento.denisferrari.com Twitter: @denisferrari

Mais conteúdo relacionado

Mais procurados

Test driven development
Test driven developmentTest driven development
Test driven development
Carlos Eduardo Miranda
 
Implementando Testes Unitários em Java - Manoel Pimentel
Implementando Testes Unitários em Java - Manoel PimentelImplementando Testes Unitários em Java - Manoel Pimentel
Implementando Testes Unitários em Java - Manoel Pimentel
Manoel Pimentel Medeiros
 
Desenvolvimento Dirigido por Testes com Junit
Desenvolvimento Dirigido por Testes com JunitDesenvolvimento Dirigido por Testes com Junit
Desenvolvimento Dirigido por Testes com Junit
Adolfo Neto
 
Junit 4.0
Junit 4.0Junit 4.0
Junit 4.0
elliando dias
 
Testes de Sofware
Testes de SofwareTestes de Sofware
Testes de Sofware
elliando dias
 
Junit
JunitJunit
Introdução ao TDD
Introdução ao TDDIntrodução ao TDD
Introdução ao TDD
Thiago Faria de Andrade
 
Introdução a testes automatizados
Introdução a testes automatizadosIntrodução a testes automatizados
Introdução a testes automatizados
Thiago Ghisi
 
Testes Automatizados de Software
Testes Automatizados de SoftwareTestes Automatizados de Software
Testes Automatizados de Software
Maurício Aniche
 
Testes de Unidade com JUnit
Testes de Unidade com JUnitTestes de Unidade com JUnit
Testes de Unidade com JUnit
elliando dias
 
Palestra Testes De Unidade Com JUnit
Palestra Testes De Unidade Com JUnitPalestra Testes De Unidade Com JUnit
Palestra Testes De Unidade Com JUnit
Paulo César M Jeveaux
 
Testes Unitários
Testes UnitáriosTestes Unitários
Testes Unitários
Jadson Santos
 
Refactory Worshop
Refactory WorshopRefactory Worshop
Refactory Worshop
guestd37c23
 
Treinamento Testes Unitários - parte 1
Treinamento Testes Unitários - parte 1Treinamento Testes Unitários - parte 1
Treinamento Testes Unitários - parte 1
Diego Pacheco
 
TDD - Test Driven Development
TDD - Test Driven DevelopmentTDD - Test Driven Development
TDD - Test Driven Development
Engenharia de Software Ágil
 
Introdução ao TDD (Test-Driven Development) - #guma10anos
Introdução ao TDD (Test-Driven Development) - #guma10anosIntrodução ao TDD (Test-Driven Development) - #guma10anos
Introdução ao TDD (Test-Driven Development) - #guma10anos
Dionatan default
 
TDD (Test-Driven Development)
TDD (Test-Driven Development)TDD (Test-Driven Development)
TDD (Test-Driven Development)
Renato Groff
 
TDD Desenvolvimento orientado ao teste
TDD Desenvolvimento orientado ao testeTDD Desenvolvimento orientado ao teste
TDD Desenvolvimento orientado ao teste
Rafaela Prado
 
Tdd x testes unidades
Tdd x testes unidadesTdd x testes unidades
Tdd x testes unidades
Simone Pittner
 
1° Madrugada de Testes
1° Madrugada de Testes1° Madrugada de Testes
1° Madrugada de Testes
Leonardo Lourenço Silva
 

Mais procurados (20)

Test driven development
Test driven developmentTest driven development
Test driven development
 
Implementando Testes Unitários em Java - Manoel Pimentel
Implementando Testes Unitários em Java - Manoel PimentelImplementando Testes Unitários em Java - Manoel Pimentel
Implementando Testes Unitários em Java - Manoel Pimentel
 
Desenvolvimento Dirigido por Testes com Junit
Desenvolvimento Dirigido por Testes com JunitDesenvolvimento Dirigido por Testes com Junit
Desenvolvimento Dirigido por Testes com Junit
 
Junit 4.0
Junit 4.0Junit 4.0
Junit 4.0
 
Testes de Sofware
Testes de SofwareTestes de Sofware
Testes de Sofware
 
Junit
JunitJunit
Junit
 
Introdução ao TDD
Introdução ao TDDIntrodução ao TDD
Introdução ao TDD
 
Introdução a testes automatizados
Introdução a testes automatizadosIntrodução a testes automatizados
Introdução a testes automatizados
 
Testes Automatizados de Software
Testes Automatizados de SoftwareTestes Automatizados de Software
Testes Automatizados de Software
 
Testes de Unidade com JUnit
Testes de Unidade com JUnitTestes de Unidade com JUnit
Testes de Unidade com JUnit
 
Palestra Testes De Unidade Com JUnit
Palestra Testes De Unidade Com JUnitPalestra Testes De Unidade Com JUnit
Palestra Testes De Unidade Com JUnit
 
Testes Unitários
Testes UnitáriosTestes Unitários
Testes Unitários
 
Refactory Worshop
Refactory WorshopRefactory Worshop
Refactory Worshop
 
Treinamento Testes Unitários - parte 1
Treinamento Testes Unitários - parte 1Treinamento Testes Unitários - parte 1
Treinamento Testes Unitários - parte 1
 
TDD - Test Driven Development
TDD - Test Driven DevelopmentTDD - Test Driven Development
TDD - Test Driven Development
 
Introdução ao TDD (Test-Driven Development) - #guma10anos
Introdução ao TDD (Test-Driven Development) - #guma10anosIntrodução ao TDD (Test-Driven Development) - #guma10anos
Introdução ao TDD (Test-Driven Development) - #guma10anos
 
TDD (Test-Driven Development)
TDD (Test-Driven Development)TDD (Test-Driven Development)
TDD (Test-Driven Development)
 
TDD Desenvolvimento orientado ao teste
TDD Desenvolvimento orientado ao testeTDD Desenvolvimento orientado ao teste
TDD Desenvolvimento orientado ao teste
 
Tdd x testes unidades
Tdd x testes unidadesTdd x testes unidades
Tdd x testes unidades
 
1° Madrugada de Testes
1° Madrugada de Testes1° Madrugada de Testes
1° Madrugada de Testes
 

Semelhante a TDD (Resumo)

Paletra sobre TDD, ocorrida no #DevDojo
Paletra sobre TDD, ocorrida no #DevDojoPaletra sobre TDD, ocorrida no #DevDojo
Paletra sobre TDD, ocorrida no #DevDojo
flavio1110
 
Desenvolvimento Dirigido por Testes
Desenvolvimento Dirigido por TestesDesenvolvimento Dirigido por Testes
Desenvolvimento Dirigido por Testes
Camilo Ribeiro
 
1 2 3 - Testando - Automatizando os testes de software
1 2 3 - Testando - Automatizando os testes de software1 2 3 - Testando - Automatizando os testes de software
1 2 3 - Testando - Automatizando os testes de software
Heider Lopes
 
Teste Driven Development
Teste Driven DevelopmentTeste Driven Development
Teste Driven Development
Eduardo Carvalho
 
TDD para "meros mortais"
TDD para "meros mortais"TDD para "meros mortais"
TDD para "meros mortais"
thiagobapt
 
Qualidade no desenvolvimento de Software com TDD e PHPUnit
Qualidade no desenvolvimento de Software com TDD e PHPUnitQualidade no desenvolvimento de Software com TDD e PHPUnit
Qualidade no desenvolvimento de Software com TDD e PHPUnit
Domingos Teruel
 
Desenvolvimento dirigido por comportamento e por teste
Desenvolvimento dirigido por comportamento e por testeDesenvolvimento dirigido por comportamento e por teste
Desenvolvimento dirigido por comportamento e por teste
Universidade Tiradentes
 
O que seus testes garantem, o funcionamento do código ou das funcionalidades ...
O que seus testes garantem, o funcionamento do código ou das funcionalidades ...O que seus testes garantem, o funcionamento do código ou das funcionalidades ...
O que seus testes garantem, o funcionamento do código ou das funcionalidades ...
Isaac de Souza
 
Test-Driven Development (TDD) utilizando o framework xUnit.net
Test-Driven Development (TDD) utilizando o framework xUnit.netTest-Driven Development (TDD) utilizando o framework xUnit.net
Test-Driven Development (TDD) utilizando o framework xUnit.net
Renato Groff
 
O que é Teste de Software?
O que é Teste de Software?O que é Teste de Software?
O que é Teste de Software?
testedesoftwarepe
 
Unit Testing
Unit TestingUnit Testing
Unit Testing
Robson Agapito Correa
 
Testes de Unidade com Junit
Testes de Unidade com JunitTestes de Unidade com Junit
Testes de Unidade com Junit
cejug
 
Introdução ao TDD
Introdução ao TDDIntrodução ao TDD
Introdução ao TDD
gustavoferrazfontes
 
Teste de Integração - Unidade III
Teste de Integração - Unidade IIITeste de Integração - Unidade III
Teste de Integração - Unidade III
João Lourenço
 
Introdução à Engenharia de Testes de Software
Introdução à Engenharia de Testes de SoftwareIntrodução à Engenharia de Testes de Software
Introdução à Engenharia de Testes de Software
Cloves da Rocha
 
Testes de Unidade com JUnit
Testes de Unidade com JUnitTestes de Unidade com JUnit
Testes de Unidade com JUnit
Denis L Presciliano
 
JUnit Sample
JUnit SampleJUnit Sample
TDD Primeiro Contato
TDD Primeiro ContatoTDD Primeiro Contato
TDD Primeiro Contato
Guilherme Botossi
 
Test driven development
Test driven developmentTest driven development
Test driven development
clauvane1708
 
Os Benefícios dos testes no desenvolvimento de software
Os Benefícios dos testes no desenvolvimento de softwareOs Benefícios dos testes no desenvolvimento de software
Os Benefícios dos testes no desenvolvimento de software
Dextra Sistemas / Etec Itu
 

Semelhante a TDD (Resumo) (20)

Paletra sobre TDD, ocorrida no #DevDojo
Paletra sobre TDD, ocorrida no #DevDojoPaletra sobre TDD, ocorrida no #DevDojo
Paletra sobre TDD, ocorrida no #DevDojo
 
Desenvolvimento Dirigido por Testes
Desenvolvimento Dirigido por TestesDesenvolvimento Dirigido por Testes
Desenvolvimento Dirigido por Testes
 
1 2 3 - Testando - Automatizando os testes de software
1 2 3 - Testando - Automatizando os testes de software1 2 3 - Testando - Automatizando os testes de software
1 2 3 - Testando - Automatizando os testes de software
 
Teste Driven Development
Teste Driven DevelopmentTeste Driven Development
Teste Driven Development
 
TDD para "meros mortais"
TDD para "meros mortais"TDD para "meros mortais"
TDD para "meros mortais"
 
Qualidade no desenvolvimento de Software com TDD e PHPUnit
Qualidade no desenvolvimento de Software com TDD e PHPUnitQualidade no desenvolvimento de Software com TDD e PHPUnit
Qualidade no desenvolvimento de Software com TDD e PHPUnit
 
Desenvolvimento dirigido por comportamento e por teste
Desenvolvimento dirigido por comportamento e por testeDesenvolvimento dirigido por comportamento e por teste
Desenvolvimento dirigido por comportamento e por teste
 
O que seus testes garantem, o funcionamento do código ou das funcionalidades ...
O que seus testes garantem, o funcionamento do código ou das funcionalidades ...O que seus testes garantem, o funcionamento do código ou das funcionalidades ...
O que seus testes garantem, o funcionamento do código ou das funcionalidades ...
 
Test-Driven Development (TDD) utilizando o framework xUnit.net
Test-Driven Development (TDD) utilizando o framework xUnit.netTest-Driven Development (TDD) utilizando o framework xUnit.net
Test-Driven Development (TDD) utilizando o framework xUnit.net
 
O que é Teste de Software?
O que é Teste de Software?O que é Teste de Software?
O que é Teste de Software?
 
Unit Testing
Unit TestingUnit Testing
Unit Testing
 
Testes de Unidade com Junit
Testes de Unidade com JunitTestes de Unidade com Junit
Testes de Unidade com Junit
 
Introdução ao TDD
Introdução ao TDDIntrodução ao TDD
Introdução ao TDD
 
Teste de Integração - Unidade III
Teste de Integração - Unidade IIITeste de Integração - Unidade III
Teste de Integração - Unidade III
 
Introdução à Engenharia de Testes de Software
Introdução à Engenharia de Testes de SoftwareIntrodução à Engenharia de Testes de Software
Introdução à Engenharia de Testes de Software
 
Testes de Unidade com JUnit
Testes de Unidade com JUnitTestes de Unidade com JUnit
Testes de Unidade com JUnit
 
JUnit Sample
JUnit SampleJUnit Sample
JUnit Sample
 
TDD Primeiro Contato
TDD Primeiro ContatoTDD Primeiro Contato
TDD Primeiro Contato
 
Test driven development
Test driven developmentTest driven development
Test driven development
 
Os Benefícios dos testes no desenvolvimento de software
Os Benefícios dos testes no desenvolvimento de softwareOs Benefícios dos testes no desenvolvimento de software
Os Benefícios dos testes no desenvolvimento de software
 

Mais de Denis Ferrari

Arquitetura evolutiva - DNAD 2013
Arquitetura evolutiva - DNAD 2013Arquitetura evolutiva - DNAD 2013
Arquitetura evolutiva - DNAD 2013
Denis Ferrari
 
Empreendedorismo - Ao vivo e sem retoques
Empreendedorismo - Ao vivo e sem retoquesEmpreendedorismo - Ao vivo e sem retoques
Empreendedorismo - Ao vivo e sem retoques
Denis Ferrari
 
DevInCachu 2013: Arquitetura evolutiva
DevInCachu 2013: Arquitetura evolutivaDevInCachu 2013: Arquitetura evolutiva
DevInCachu 2013: Arquitetura evolutiva
Denis Ferrari
 
10 coisas que aprendi com o tempo
10 coisas que aprendi com o tempo10 coisas que aprendi com o tempo
10 coisas que aprendi com o tempo
Denis Ferrari
 
UCL Innovation Party - Framework .NET
UCL Innovation Party - Framework .NETUCL Innovation Party - Framework .NET
UCL Innovation Party - Framework .NET
Denis Ferrari
 
Desenvolvimento de software - Mercado e Carreira
Desenvolvimento de software - Mercado e CarreiraDesenvolvimento de software - Mercado e Carreira
Desenvolvimento de software - Mercado e Carreira
Denis Ferrari
 
Previsibilidade em desenvolvimento de software
Previsibilidade em desenvolvimento de softwarePrevisibilidade em desenvolvimento de software
Previsibilidade em desenvolvimento de software
Denis Ferrari
 
Desenvolvimento orientado a Testes
Desenvolvimento orientado a TestesDesenvolvimento orientado a Testes
Desenvolvimento orientado a Testes
Denis Ferrari
 
Apresentação sobre Coding Dojo
Apresentação sobre Coding DojoApresentação sobre Coding Dojo
Apresentação sobre Coding Dojo
Denis Ferrari
 
AOP
AOPAOP

Mais de Denis Ferrari (10)

Arquitetura evolutiva - DNAD 2013
Arquitetura evolutiva - DNAD 2013Arquitetura evolutiva - DNAD 2013
Arquitetura evolutiva - DNAD 2013
 
Empreendedorismo - Ao vivo e sem retoques
Empreendedorismo - Ao vivo e sem retoquesEmpreendedorismo - Ao vivo e sem retoques
Empreendedorismo - Ao vivo e sem retoques
 
DevInCachu 2013: Arquitetura evolutiva
DevInCachu 2013: Arquitetura evolutivaDevInCachu 2013: Arquitetura evolutiva
DevInCachu 2013: Arquitetura evolutiva
 
10 coisas que aprendi com o tempo
10 coisas que aprendi com o tempo10 coisas que aprendi com o tempo
10 coisas que aprendi com o tempo
 
UCL Innovation Party - Framework .NET
UCL Innovation Party - Framework .NETUCL Innovation Party - Framework .NET
UCL Innovation Party - Framework .NET
 
Desenvolvimento de software - Mercado e Carreira
Desenvolvimento de software - Mercado e CarreiraDesenvolvimento de software - Mercado e Carreira
Desenvolvimento de software - Mercado e Carreira
 
Previsibilidade em desenvolvimento de software
Previsibilidade em desenvolvimento de softwarePrevisibilidade em desenvolvimento de software
Previsibilidade em desenvolvimento de software
 
Desenvolvimento orientado a Testes
Desenvolvimento orientado a TestesDesenvolvimento orientado a Testes
Desenvolvimento orientado a Testes
 
Apresentação sobre Coding Dojo
Apresentação sobre Coding DojoApresentação sobre Coding Dojo
Apresentação sobre Coding Dojo
 
AOP
AOPAOP
AOP
 

Último

Manual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdfManual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdf
WELITONNOGUEIRA3
 
História da Rádio- 1936-1970 século XIX .2.pptx
História da Rádio- 1936-1970 século XIX   .2.pptxHistória da Rádio- 1936-1970 século XIX   .2.pptx
História da Rádio- 1936-1970 século XIX .2.pptx
TomasSousa7
 
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdfEscola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Gabriel de Mattos Faustino
 
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
Faga1939
 
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdfTOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
Momento da Informática
 
Logica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptxLogica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptx
Momento da Informática
 
Segurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas PráticasSegurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas Práticas
Danilo Pinotti
 

Último (7)

Manual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdfManual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdf
 
História da Rádio- 1936-1970 século XIX .2.pptx
História da Rádio- 1936-1970 século XIX   .2.pptxHistória da Rádio- 1936-1970 século XIX   .2.pptx
História da Rádio- 1936-1970 século XIX .2.pptx
 
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdfEscola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
 
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
 
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdfTOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
 
Logica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptxLogica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptx
 
Segurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas PráticasSegurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas Práticas
 

TDD (Resumo)

  • 2. SobreDenis Ferrari GraduandoemSistemas de informaçãopelaFAESA; Arquiteto de software; Ministrapalestras e treinamentos; Consultor de negócios; MCP, MCTS (Web Applications e Distributed Applications), MCPD (Web Applications); EscreveartigosparaosportaisImasters, Linha de código e osdisponibilizatambémemseu blog. 9 anos de experiência no mercado de TI capixabaatuandocomoInstrutor, Web Master, DesenvolvedorSênior e Gerente de Projetos;
  • 3. Objetivosdapalestra Apresentar a metodologiaágile seusvalores. Apresentar o desenvolvimentoorientado a testescomoumaalternativaaodesenvolvimentotradicional.
  • 5. 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
  • 6. 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-DrivenDevelopment, 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.
  • 7. Conceitos DEFINIÇÃO:Movimento iniciado por programadores experientes e consultoresem 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/
  • 8. Assinaram o manifesto: Kent Beck, Mike Beedle, Arie van Bennekum, AlistairCockburn,WardCunningham, 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.
  • 9. TDD
  • 10. 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)
  • 11. 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)
  • 12. 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
  • 13. Testes de Unidade; Testes de Integração; Testes de Sistema; Testes de Integração de Sistema; Testes de Aceitação; Tipos de Testes
  • 14. 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
  • 15. A “Espiral da Morte” do Teste O ciclo mortal do “estou sem tempo para testar”:
  • 16. 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 “TestList” 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
  • 17. Mas o que testamos? Fluxos Condicionais (IFs, Switches, etc.) Polimorfismos Loops Operações Etc.. Princípios
  • 18. 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
  • 19. 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
  • 20. 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
  • 21. Exemplo: Testar o envio da string “Teste” através de um socket. Princípios publicvoidTestarComunicacaoSocket() { Assert.IsTrue(readerSocket.Close()); Assert.AreEqual(“Qualidata”, buf); } publicvoidTestarComunicacaoSocket() { string buf = reader.Contents(); Assert.IsTrue(readerSocket.Close()); Assert.AreEqual(“Qualidata”, buf); } publicvoidTestarComunicacaoSocket() { SocketreaderSocket = newSocket(“localhost”, 8080); string buf = reader.Contents(); Assert.IsTrue(readerSocket.Close()); Assert.AreEqual(“Qualidata”, buf); } publicvoidTestarComunicacaoSocket() { Serverserver = newServer(8080, “Teste”); SocketreaderSocket = newSocket(“localhost”, 8080); string buf = reader.Contents(); Assert.IsTrue(readerSocket.Close()); Assert.AreEqual(“Qualidata”, buf); }
  • 22. 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
  • 23. 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] publicvoid Testar_Fatorial_8() { Assert.AreEqual(40320, Matematica.Fatorial(8)); } [Test] publicvoid Testar_Fatorial_8() { Assert.AreEqual(8 * 7 * 6 * 5 * 4 * 3 * 2, Matematica.Fatorial(8)); }
  • 24. 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”
  • 25. 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”
  • 26. 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”
  • 27. 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”
  • 28. 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. MockObjects 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 RhinoMocks. “TestingPatterns”
  • 29. 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”
  • 30. “Fake it ‘til youmake 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” publicvoidTestarSoma() { Assert.AreEqual(5, Somar(2,3)); } publicvoidTestarSoma() { Assert.AreEqual(5, Somar(2,3)); } publicint Somar(int x, int y) { return 5; }
  • 31. 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 publicvoidTestarSoma() { Assert.AreEqual(5, Somar(2,3)); Assert.AreEqual(7, Somar(3,4)); }
  • 32. 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. “TestingPatterns”
  • 33.
  • 34. Informaçõesparacontato E-mail/MSN: denisferrari@live.com Gtalk: denis.sisinf@gmail.com Site: www.denisferrari.com Blog: desenvolvimento.denisferrari.com Twitter: @denisferrari