Introdução a tdd

Introdução ao Desenvolvimento Orientado a Testes (Test-DrivenDevelopment - TDD)Fabrício MatosNov/2008

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çãoPágina 2

Objetivo do TDD: “cleancodethat works”código limpo que funciona“Mantra” do TDD: vermelho-verde-refatorarCodifique 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çãoPágina 3

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 TDDPágina 4

Nosso foco é em produtos, e não em serviços, e os produtos precisam acompanhar as mudanças dos processos dos clientes, logo nossos sistemas estarão em constante evolução. Testes automáticos nos ajudarão pois: Evitarão efeitos colaterais nas futuras alterações.Documentarão bem o sistema para novos profissionais contratados.Permitirão a liberação de releases de muito maior qualidade.Erros reportados serão reproduzidos via caso de teste, corrigidos e nunca mais retornarão pois estarão cobertos pelo teste automático;Importância para QualidataPágina 5

A Metodologia TDDEstudo de Caso: Aplicação do TDD na IBMTese de Doutorado - MirkeyaCapellán(2006)Measuring Productivity and Code Quality: Test-Driven Development vs. WaterfallConstrução de Casos de Testes com NUnitConsiderações FinaisOrganização da ApresentaçãoPágina 6

A Metodologia TDDBaseado principalmente emKent BeckTest-DrivenDevelopmentByExample, 2003Página 7

Testes de Unidade: Testa uma unidade mínima do software;Testes de Integração: Testa a comunicação entre os módulos;Testes de Sistema: Testa todo o sistema para verificar se atende aos requisitos;Testes de Integração de Sistema: Testa a comunicação do sistema com outros sistemas com os quais interage;Testes de Aceitação: Testes realizados pelo usuário final para verificar se o sistema faz o que ele espera;Tipos de TestesPágina 8

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 TestesPágina 9

A “Espiral da Morte” do TestePágina 10O ciclo mortal do “estou sem tempo para testar”:

1. Construa testes isolados uns dos outrosUm 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ípiosPágina 11

Mas o que testamos?Fluxos Condicionais (IFs, Switches, etc.)PolimorfismosLoopsOperaçõesEtc..PrincípiosPágina 12

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ípiosPágina 13

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ípiosPágina 14

3. Primeiro o TesteOportunidade para pensar no design (projeto) das classesControlar 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ípiosPágina 15

Exemplo: Testar o envio da string “Qualidata” através de um socket.PrincípiosPágina 16publicvoidTestarComunicacaoSocket() {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, “”Qualidata”);SocketreaderSocket = newSocket(“localhost”, 8080); string buf = reader.Contents();Assert.IsTrue(readerSocket.Close());Assert.AreEqual(“Qualidata”, buf); }

5. Dados para TesteNã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 aproveitadosPrincípiosPágina 17

6. Dados com Significado EvidenteLembre 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ípiosPágina 18 [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”Página 19

Testes de EstudoDevemos 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”Página 20

Testes de Outras FuncionalidadesSempre 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.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”Página 21

Defeitos ReportadosSempre 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ãoConsiste 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”Página 22

Técnicas mais detalhadas sobre como escrever testes.Subdividir TestesQuando 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.MockObjectsComo 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.comFerramentas para .NET: NMock e RhinoMocks.“TestingPatterns”Página 23

Log StringComo testar se uma sequência de métodos foi chamada numa certa ordem?Guarde um log (trace log) de cada execução dos métodos chamados em uma string e compare com o valor esperado. Teste de FalhasPrecisamos assumir que “código que não foi testado não funciona”. Mas como testar falhas que são difíceis de se reproduzir (disco cheio, falha de comunicação, etc.)?“Fake it!”, ou seja, construa uma nova classe que gere a exceção e simule a falha.“TestingPatterns”Página 24

Desenvolvendo Sozinho – Teste QuebradoSe você está desenvolvendo uma software sozinho, é sempre melhor encerrar uma sessão de programação deixando um teste vermelho(incompleto). Isso agiliza a continuação do trabalho no próximo dia.Desenvolvimento em Equipe – Testes RodandoSe você trabalha em equipe, não faça check-in de testes vermelhos. Isso vai ser ruim pois todos vão achar que há um requisito que foi “estragado”, enquanto na verdade ele ainda não foi finalizado.Ao subir suas alterações (check-in), rode todos os testes para garantir a integração entre os módulos.Se os testes não forem muito lentos, procure rodar todos os testes em sua própria estação para antecipar problemas de integração.“TestingPatterns”Página 25

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”Página 26

“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”Página 27publicvoidTestarSoma() {Assert.AreEqual(5, Somar(2,3)); }publicvoidTestarSoma() {Assert.AreEqual(5, Somar(2,3)); }publicint Somar(int x, int y) {return 5; }

TriangulaçãoQuando 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 28publicvoidTestarSoma() {Assert.AreEqual(5, Somar(2,3));Assert.AreEqual(7, Somar(3,4)); }

Implementação ÓbviaSe 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”Página 29

Operações Sobre ColeçõesImplemente primeiro o teste para a operação recebendo um elemento;Depois estenda para a operação recebendo a coleção;Testes de ExceçõesComo testar se em determinadas condições uma exceção é gerada?Use try ... Teste ... Assert.IsTrue(false) ... catch ...Ou use algum recurso específico do seu framework de testes (um “xUnit” da vida), se houver:“TestingPatterns”Página 30 [ExpectedException(typeof(QException), "O atributo Pessoa.Nome não pode ser nulo.")]publicvoidTestarNomeNaoNulo() { Pessoa p = new Pessoa();Conexao.Save(p); }

É muito importante pensar em “design patterns” ao projetar seu software;Em TDD, “projeto” (design) não é exatamente uma fase, mas parte do processo “vermelho-verde-refatorar”. Nesse sentido eles recebem um olhar um pouco diferente em TDD.Apenas para ilustrar, vamos destacar um “design patterns” bem interessante.“Design Patterns”Página 31

Objeto NULLQuantas vezes você já viu uma “nullreference exception”?Quantas vezes você precisou proteger o seu código com um “if (obj != null) ...” ?Ao invés de retornar “null”, pode ser melhor retornar um objeto especial, com a mesma interface, mas que não gere problemas. Exemplo (java.io.File):“Design Patterns”Página 32publicbooleansetReadOnly() {SecurityManagerguard = System.getSecurityManager();if (guard != null) {guard.canWrite(path); }returnfileSystem.setReadOnly(this);}publicstaticSecurityManagergetSecurityManager() {returnsecurity; //pode ser null}publicbooleansetReadOnly() {SecurityManagerguard = System.getSecurityManager();guard.canWrite(path);returnfileSystem.setReadOnly(this);}publicstaticSecurityManagergetSecurityManager() {returnsecurity == null ? newSecurityLiberadoGeral() : security;}

Refatorar é melhorar o “design” de funcionalidades do sistema, sem alterar seu comportamento;Em TDD, devemos refatorar mantendo todos os testes “verdes”;Em TDD, primeiro pensamos em resolver o problema daPor que refatorar o código?Para torná-lo mais legível;Para facilitar sua manutenção, seja na correção de bugs ou na adição de novas funcionalidades, aumentado assim sua vida útil;Para ajustar decisões de projeto estejam impactando negativamente o sistema (limitando, deixando lento, etc..)Para buscar o “clean” de “cleancodethat works”Embora seja um assunto que possa ser trabalhado de forma mais específica, trabalharemos alguns exemplos de técnicas de refatoração de código.“Refactoring”Página 33

Reconcilie DiferençasSe duas partes do código poderem ser iguais, então poderemos eliminar uma delas;Dois loops poderiam ser fundidos em um só;Se dois caminhos em um condicional forem iguais, poderemos eliminar a condição;Se dois métodos foram iguais, podemos eliminar um;Se duas classes forem iguais, podemos eliminar uma;“Refactoring”Página 34

Isole as AlteraçõesSe você precisa alterar uma parte específica de um método divido em partes (seções), primeiro isole essa parte (refatoração) e depois faça a alteração;Migrar DadosComo migrar dados de uma estrutura para outra? (Por exemplo, de um DataSet para uma lista)Duplique os dados primeiro criando uma nova variável (mantenha o DataSet e crie também a lista)Inicialize também a nova variável (lista) em todo lugar que a antiga (DataSet) é inicializada;Substitua a implementação para que seja utilizada a nova estrutura variável (lista) ao invés da antiga (DataSet)Elimine a variável da estrutura original (o DataSet).Entre todos esses passos os testes não devem deixar de permanecer verde.“Refactoring”Página 35

Extraia MétodosSimplifique métodos muito longos, criando métodos menores (variáveis locais utilizadas também fora do trecho devem virar parâmetros)Não se deve ir tão longe ao ponto de criar tantas indireções que acabem dificultando a leitura.Blocos de código com aquele típico comentário no início são excelentes candidatos a novos métodos. Exemplo:“Refactoring”Página 36 //Verifica se o aluno atende a todos os pré-requisitos para ser matriculado linha 1 linha 2 ... linha N

Métodos “Inline”Esse é o ato de substituir uma chamada de um método pelo seu conteúdo (o oposto da técnica anterior)Isso é especialmente útil quando você está tendo dificuldade de entender um código confuso, cheio de indireções. Nesses casos pode ser melhor simplesmente desfazer (via “inline”) algumas camadas de abstração, entender o que o código faz, e depois repensar a melhor forma de reorganizá-lo.“Refactoring”Página 37

Mover MétodosComo mover métodos para outros “lugares” sem exigir uma alteração imediata em todos as suas chamadas?Crie o novo método no lugar que deseja;Mova o conteúdo do método;No método original, faça uma chamada ao novo método, repassando os parâmetros.Adicionar Novo ParâmetroPode ser visto como um caso de “Migrar Dados”Também pode ser utilizado o próprio compilador para mostrar onde será necessário alterar sua chamada;“Refactoring”Página 38

Mover Parametros de Métodos para ConstrutoresPor que? Se você passa o mesmo parâmetro para vários métodos de uma classe, pode ser melhor passá-lo uma única vez em seu constructor, e simplificar as chamadas dos métodos;Como?Adicione o parâmetro ao constructor;Adicione uma nova variável de instância com o mesmo nome do parâmetro, e inicialize ela no constructor;Um por um, converta todas as ocorrências de “parametro” nos métodos por “this.parametro”.“Refactoring”Página 39

Mover Parametros de Métodos para Construtores (...continuação)Quando não houver mais referências a “parametro”, elimine-o da assinatura do método e de todas suas chamadas;Remova o “this.” que agora é supérfluo;Renomeie a variável de instância apropriadamente.“Refactoring”Página 40

Qual o tamanho ideal dos passos “vermelho-verde-refatorar”?Você pode escrever testes que vão te levar a escrever uma única linha de código;Também pode escrever testes que vão te levar à escrever centenas de linha de código;Não há uma regra, mas a tendência dos experientes em TDD é clara: Passos pequenos.“Mastering TDD”Página 41

Características de um bom testeSe você tem dificuldade para identificar um lugar comum para inicializações compartilhadas, então você deve ter um problema de projeto – muitos objetos entrelaçados.Quanto feedback (asserts) você precisa?Depende. Por exemplo, pode ser muito improvável um problema de diskfull, e você está confiante que esse é um teste desnecessário no cenário do software em questão.“Mastering TDD”Página 42

Quando excluir um teste?Quanto mais testes, melhor;Se dois testes fazem a mesma coisa, pode ser, mas considere:Na dúvida, não exclua;Se os dois testes seguem o mesmo fluxo de execução, mas comunicam (documentam) questões diferentes, deixe-os assim.TDD é Escalável?O maior sistema totalmente TDD que o autor participou foi na LifeWare:40 pessoas, por 4 anos250KLOC de código funcional250KLOC de código de teste4000 testes que levam 20min para executar“Mastering TDD”Página 43

Como iniciar TDD em um sistema desenvolvido sem Testes Automatizados?Muitos livros ainda precisam ser escritos sobre isso;Um primeiro problema é que código que não foi escrito pensando nos testes é difícil de ser testado;Outro problema é que alterações nesse código são perigosas pois não temos os testes para garantir que tudo continua funcionando;O ideal seria primeiramente implementar testes automáticos para todo o sistema e depois partir para desenvolver as novas funcionalidades com TDD;Outra opção é explorar outras formas de feedback, como testes de nível de aplicação, que garanta certo nível de confiança.“Mastering TDD”Página 44

A Metodologia TDDEstudo de Caso: Aplicação do TDD na IBMTese de Doutorado - MirkeyaCapellán (2006)Measuring Productivity and Code Quality: Test-Driven Development vs. WaterfallConstrução de Casos de Testes com NUnitConsiderações FinaisOrganização da ApresentaçãoPágina 45

Baseado no artigo: [1] E. M. Maximilien and L. Williams, "Assessing test-driven development at IBM", Proceedings of the 25th International Conference on Software Engineering pp. 564-569, Portland, Oregon, USA, IEEE Computer Society, 2003.O sistema: JavaPOS (www.javapos.com) Um conjunto de serviços (JavaBeans) para permitir o acesso a dispositivos POS (pointofsale), tais como impressoras, caixas (dinheiro), leitores magnéticos, etc..Implementado através de uma parceria da IBM, NCR, Epson e Sun.TDD na IBMPágina 46

MotivaçãoImplementação do JavaPOS original (sem TDD) contava com uma equipe que conehcia muito bem suas especificações e tinha grande experiência com dispositivos POS;Em cada fase de FVT (Functional Verification Test), executada antes de cada novo release, a taxa de defeitosnãodiminuíacomoesperado.Porissodesenvolvedores e gerentesestavamabertos a novas abordagens.TDD na IBMPágina 47

Experiência Anterior com TestesCriavam algumas classes de teste de forma ad-hoc para partes mais importantes do código;O processo de construção de testes não era sistemático, sendo uma atividade pós-desenvolvimento;Na maioria das vezes, nenhum teste era criado. Especialmente quando os cronogramas estavam apertados, os desenvolvedores precisavam parar para resolver problemas de desenvolvimentos anteriores, ou ainda os novos requisitos não estavam muito clarosTDD na IBMPágina 48

Experiência Anterior com Testes (cont.)A maioria dos testes de unidade eram desperdiçados;Eles não eram executados na fase de verificação funcional (FVT)Também não eram aproveitados em versões posteriores (novos releases) do software;Não tinham qualquer experiência com TDD.TDD na IBMPágina 49

Adoção da Metodologia TDD - No início havia muitas dúvidas:Taxa de Defeitos – Como TDD vai afetar a taxa de defeitos a curto prazo (próximo release) e a longo prazo (futuros releases)?Produtividade - Qual será o impacto? Trabalhavam com uma média de 400LOC / pessoa-mês.Frequência dos Testes – Qual será o percentual de testes automatizados em relação a testes iterativos? Quão frequentemente cada tipo de teste será executado?Projeto – Como TDD vai afetar a qualidade do projeto (design)? Eles avaliam isso através da capacidade de lidar com requisitos identificados tardiamente, ou a inclusão de novos dispositivos ou serviços.Integração – TDD e seus testes de regressão automatizados irão suavizar os processos de integração?TDD na IBMPágina 50

O Trabalho com TDDNo início muitos desenvolvedores e gerentes estavam preocupados pois uma metodologia tão rigorosa poderia afetar a produtividade a ponto de inviabilizar a manutenção dos cronogramas existentes.Apesar das metodologias ágeis sugerirem nenhum projeto a priori, no javaPOS os requisitos eram bem estáveis, e a equipe optou por desenvolver diagramas de classes e de sequência;Acrescentaram nas atividades de projeto, além dos diagramas UML, a criação de casos de teste (teste de sistema);TDD na IBMPágina 51

O Trabalho com TDDPara cada classe pública A, tinham uma classe TesteA, e para cada método de A, métodos de teste correspondentes em TesteA.Havia casos em que era necessário tratar cenários diferentes do mesmo caso de teste. Por exemplo, impressoras que trabalhavam de modo síncrono ou assíncrono, exigiam casos de teste específicos para cada cenário;Definiram como meta um mínimo de 80% de cobertura de teste automatizado (o restante poderia ser testes iterativos);TDD na IBMPágina 52

O Trabalho com TDDCada documento de especificação de projeto continha uma secção de testes descrevendo todas as classes e métodos importantes que deveriam ser testados;Diariamente todo código era compilado automaticamente, e todos os testes executados.Para cada build, um email era enviado para cada membro da equipe com a lista de testes executados e eventuais erros encontrados.Em um primeiro momento, esses builds eram gerados várias vezes por dia;TDD na IBMPágina 53

ResultadosNúmeros do Projeto:71.4 KLOC de código de negócio e 34 KLOC de código Junit;Densidade de erros, que normalmente é de 8 erros/KLOC foi de 4 erros/KLOC (50% de redução)OBS: Atualmente, devido ao TDD, nossa densidade média de erros é de 3.7 erros/KLOC.Foram escritos 2390 casos de teste JUnit. Outros 100 testes foram escritos para avaliar performance;TDD na IBMPágina 55

ResultadosTaxa de Defeitos – Com TDD, os testes automatizados realmente foram feitos. Como resultado obtiveram um excelente redução de 50% de defeitos na fase de verificação funcional (FVT)Produtividade – Não só manteve-se dentro dos cronogramas, como obtiveram uma pequena melhoria em relação à média de 400LOC/pessoa-mês;Frequência dos Testes – Escreveram aproximadamente 2500 testes automáticos e 400 testes iterativos, ou seja, 86% de cobertura de teste automático, acima da meta de 80%.Projeto – Acreditam que TDD ajudou a produzir um sistema que recebe mais facilmente mudanças. Inclusive alguns dispositivos foram incluídos no projeto quando o mesmo já tinha avançado mais de 2/3 do cronograma.Integração – Antes integravam somente próxima à fase de FVT. Com TDD e integrações (builds) diários, diminuíram muito os riscos pois problemas aparecem bem mais cedo.TDD na IBMPágina 56

Lições aprendidas sobre a transição para TDD:Comece TDD no início do projeto;Ajuste as expectativas da equipe pois no início TDD parece menos produtivo e frustrante pelo tempo que se leva para criar os testes; Na prática, no final das contas, não haverá impacto negativo na produtividade.Para uma equipe nova em TDD, inicie builds diários mais adiante um pouco. Não muito cedo nem muito tarde (após 1/3 do cronograma, por exemplo). Enquanto isso cada um deve executar os seus testes em sua estação.TDD na IBMPágina 57

Lições aprendidas sobre a transição para TDD:Convença a equipe de adicionar novos casos de tese sempre que um problema for encontrado, não importando onde seja. Isso vai garantir a solução do problema em algum momento à frente;Definimos 80% de cobertura como um objetivo mínimo. É extremamente importante os builds diários automáticos. Eles se tornam a batida que dá o ritmo ao projeto e ao mesmo tempo facilita acompanharmos seu progresso;Encorage a construção de testes que executem rapidamente e de projeto eficiente;Aproveite sempre para encorajar a equipe a escrever mais testes, por exemplo, monitorando qual subsistema tem mais testes implementados.TDD na IBMPágina 58

Experimento24 profissionais de 3 empresas trabalhando em pares. Metade com TDD e a outra metade seguindo um Modelo em Cascata. Apenas uma empresa tinha experiência prévia com TDD;Resultados:TDD produziu um código de mais qualidade do que o Modelo Cascata18% a mais de sucesso em testes de caixa preta80% mais eficaz em termos de qualidade de códigoTDD teve um tempo total de desenvolvimento bem menor:O de programação, especificamente, foi 16% maior; O projeto como um todo foi 78% mais podutivo;Programadores acharam TDD uma forma mais simples de projetar software;Transição para TDD foi difícilTDD versus ModeloCascataPágina 60

Introdução a tdd

Mais conteúdo relacionado

Mais procurados (20)

Destaque (20)

Semelhante a Introdução a tdd (20)

Mais de Fabrício Vargas Matos (10)

Último (8)

Introdução a tdd