Test Driven Development (TDD) ou em português Desenvolvimento dirigido por testes é uma técnica de desenvolvimento de software que se relaciona com o conceito de verificação e validação e se baseia em um ciclo curto de repetições:

Primeiramente o desenvolvedor escreve um caso de teste automatizado que define uma melhoria desejada ou uma nova funcionalidade.

Então, é produzido código que possa ser validado pelo teste para posteriormente o código ser refatorado para um código sob padrões aceitáveis.

Já falamos na nossa série Agile Methods1 sobre Crystal, DSDM, LSD, Kanban, Extreme Programming, FDD e hoje vamos falar de TDD.

O que você vai ver neste artigo?

  • O que é Test-Driven Development (TDD): O que é o TDD e por queTest-Driven Development usar
  • História do Test-Driven Development (TDD): De onde veio o Desenvolvimento Dirigido por Testes, quem o descobriu? Veio dos anos 90 ou dos anos 60?
  • Práticas de TDD: Como funciona passo-a-passo.
  • Escalonando o TDD por meio do Agile Model Driven Development (AMDD): Utilizando ciclos ágeis para escalar o TDD.
  • O ciclo de vida da AMDD: Como funciona o Agile Model Driven Development
  • TDD e AMDD e Scrum: Comparativo entre os três.

O que é Test-Driven Development (TDD)

Kent Beck, considerado o criador ou o ‘descobridor’ da técnica, declarou em 2003 que TDD encoraja designs de código simples e inspira confiança.2

Entretanto o Desenvolvimento dirigido por testes é relacionado a conceitos de programação do Extreme Programming, iniciado em 1999, mas recentemente tem-se criado maior interesse pela mesma em função de seus próprios ideais.3

Através do TDD, programadores podem aplicar o conceito de melhorar e depurar código legado desenvolvido a partir de técnicas antigas.4

História do Test-Driven Development (TDD)

Tenho visto pessoas me apontando para muitas “origens” diferentes de TDD. Alguns me indicarão a redescoberta de Kent Beck no final dos anos 1990 com o XP.

Outros mencionarão a melhor prática da década de 1960 de anotar os resultados nas laterais dos cartões perfurados para verificar as coisas com mais rapidez e precisão.

E, ainda assim, alguns me indicarão vários livros sobre confiabilidade de software que datam das décadas de 1960 e 1990.

O termo de Test-driven develpment foi emprestado do Extreme Programming, o que nos leva diretamente a Kent Beck. Navegar pela literatura especializada mostra que os termos de TDD, design dirigido por teste , teste de programação inicial e termos semelhantes só surgem após o livro de Beck.

O TDD é muito diferente das anotações em um cartão perfurado ou das práticas de confiabilidade e qualidade de software anteriores à década de 1990.

Os pioneiros da qualidade de software já argumentaram há muito tempo em favor de testes iniciais e sistemáticos.

Mas essas abordagens orientadas para a qualidade são, na melhor das hipóteses, paralelas ao desenvolvimento. Eles são realizados para evitar bugs, verificar e validar o software.

Em ” O crescimento dos testes de software “, D. Gelperin e B. Hetzel explicam em 1988, com base em uma análise muito ampla dos métodos existentes:

Os modelos de ciclo de vida movem o foco do teste do final de um projeto para o seu início. Essa mudança resulta na visão de que o teste não é uma fase sequencial que afeta apenas a implementação do software, mas está em uma trilha paralela que afeta os requisitos e projetos de software também. O teste é visto como uma forte interação com as atividades de desenvolvimento desde o início de um projeto.

Isso não significa que o teste não possa contribuir para a melhoria do design do software, como aponta o ” Guia para Testes em um Ambiente de Sistema Complexo ” da IBM em 1974:

O planejamento do teste deve começar no início do ciclo de desenvolvimento (…). Os testadores olham para as especificações de um ponto de vista totalmente diferente do que os desenvolvedores. Como tal, eles podem frequentemente detectar falhas na lógica do projeto ou a incompletude da especificação. Ao fazer isso, eles ajudam os desenvolvedores a produzir um produto superior e acelerar o desenvolvimento do programa real. ”

Porém, interagir com o design e a implementação e detectar as falhas não está impulsionando o desenvolvimento.

Portanto, ainda estávamos longe do TDD – No TDD, a escrita do teste contribui para o design.

No entanto, Beck não era o único com essa ideia em mente. Em 1992, por exemplo, um artigo sobre Simulação Orientada à Objetos do protocolo CSMA5 por H.Saiedian sugere que os testes devem preceder o projeto e construção de sistemas complexos.

O autor não inventou o TDD, pois seu artigo é sobre simulação de sistemas de telecomunicações.

Mas o surgimento dos princípios TDD está claramente na página 5:

(…) Este recurso de orientação a objetos permite que se considere experimentar uma implementação simples que consiste em objetos importantes, bem como objetos que servem como “stub” ou “driver” (ou, em geral, “placeholder” ) que pode ajudar na definição, formulação e teste de interfaces e interações de objetos; modificações subsequentes podem ser feitas no modelo para desenvolver uma implementação mais detalhada de alguns ou de todos os objetos de forma gradual e controlada.

IMHO, acho que o surgimento da orientação a objetos e abordagens de desenvolvimento iterativo estimulou esse tipo de pensamento, não excluo a possibilidade de que outras equipes usaram a abordagem TDD sem nunca terem publicado.

Entretanto se foi um Zeitgeist ou não, Beck ainda é o primeiro a fazer disso um conceito maduro.

Práticas de TDD

A sequência a seguir é baseada no livro Test-Driven Development by Example6

1. Adicione um teste

No desenvolvimento orientado a testes, cada novo recurso começa com a escrita de um teste. Escreva um teste que defina uma função ou melhorias de uma função, que deve ser muito sucinto.

Para escrever um teste, o desenvolvedor deve entender claramente as especificações e os requisitos do recurso.

O desenvolvedor pode fazer isso por meio de casos de uso e histórias de usuário para cobrir os requisitos e condições de exceção, e pode escrever o teste em qualquer estrutura de teste apropriada para o ambiente de software. Pode ser uma versão modificada de um teste existente.

Este é um recurso diferenciador do desenvolvimento orientado a testes versus a escrita de testes de unidade depois que o código é escrito: faz com que o desenvolvedor se concentre nos requisitos antes escrever o código, uma diferença sutil, mas importante.

2. Execute todos os testes e veja se o novo teste falha

Isso valida se o equipamento de teste está funcionando corretamente, mostra que o novo teste não passa sem exigir um novo código porque o comportamento necessário já existe e elimina a possibilidade de que o novo teste tenha falhas e sempre passe.

O novo teste deve falhar pelo motivo esperado. Esta etapa aumenta a confiança do desenvolvedor no novo teste.

3. Escreva o código

A próxima etapa é escrever algum código que faça com que o teste seja aprovado. O novo código escrito nesta fase não é perfeito e pode, por exemplo, passar no teste de uma forma deselegante.

Isso é aceitável porque será melhorado e aprimorado na Etapa 5.

Neste ponto, o único propósito do código escrito é passar no teste. O programador não deve escrever código que esteja além da funcionalidade que o teste verifica.

4. Execute testes

Se todos os casos de teste agora passarem, o programador pode ter certeza de que o novo código atende aos requisitos de teste e não quebra ou degrada quaisquer recursos existentes.

Caso contrário, o novo código deve ser ajustado até que o façam.

5. Refatorar código

A crescente base de código deve ser limpa regularmente durante o desenvolvimento orientado a testes.

O novo código pode ser movido de onde era conveniente para passar em um teste para onde ele pertence mais logicamente. A duplicação deve ser removida.

Nomes de objetos, classes, módulos, variáveis e métodos devem representar claramente seu propósito e uso atuais, conforme funcionalidade extra é adicionada.

Conforme os recursos são adicionados, os corpos dos métodos podem ficar mais longos e outros objetos maiores.

Eles se beneficiam de serem divididos e suas partes cuidadosamente nomeadas para melhorar a legibilidade e a manutenção, o que será cada vez mais valioso mais tarde no ciclo de vida do software.

Hierarquias de herança podem ser reorganizadas para serem mais lógicas e úteis e, talvez, para se beneficiar de padrões de design reconhecidos .

Existem diretrizes específicas e gerais para refatoração e para a criação de código limpo. 78

Continuamente reexecutando os casos de teste ao longo de cada fase de refatoração, o desenvolvedor pode ter certeza de que o processo não está alterando nenhuma funcionalidade existente.

O conceito de remoção da duplicação é um aspecto importante de qualquer projeto de software.

Nesse caso, porém, também se aplica à remoção de qualquer duplicação entre o código de teste e o código de produção – por exemplo, números mágicos ou strings repetidas em ambos para fazer o teste passar na Etapa 3.

Repetir

Começando com outro novo teste, o ciclo é repetido para levar adiante a funcionalidade.

O tamanho das etapas deve ser sempre pequeno, com apenas 1 a 10 edições entre cada execução de teste.

Se o novo código não satisfizer rapidamente um novo teste, ou outros testes falharem inesperadamente, o programador deve desfazer ou reverter de preferência para depuração excessiva.

A integração contínua ajuda ao fornecer pontos de verificação reversíveis.

Ao usar bibliotecas externas, é importante não fazer incrementos tão pequenos a ponto de estar efetivamente meramente testando a própria biblioteca9,  a menos que haja alguma razão para acreditar que a biblioteca está com bugs ou não é suficientemente completa para servir a todos as necessidades do software em desenvolvimento.

Uma representação gráfica do ciclo de vida do TDD

Escalonando o TDD por meio do Agile Model Driven Development (AMDD)

O TDD é muito bom em especificações e validação detalhadas. Ele falha em pensar em questões maiores, como design geral, uso do sistema ou UI.

AMDD aborda os problemas de dimensionamento Agile que o TDD não faz.

Assim, a AMDD é usada para problemas maiores.

O ciclo de vida da AMDD

O ciclo de vida da AMDD

Em Model-driven Development (MDD), modelos abrangentes são criados antes que o código-fonte seja escrito. Que por sua vez tem uma abordagem ágil?

Na figura acima, cada caixa representa uma atividade de desenvolvimento.

A previsão é um dos processos TDD de testes de previsão / imaginação que serão realizados durante a primeira semana do projeto.

O objetivo principal da previsão é identificar o escopo do sistema e a arquitetura do sistema.

Requisitos de alto nível e modelagem de arquitetura são feitos para uma visão bem-sucedida.

É o processo em que não é feita uma especificação detalhada do software / sistema, mas sim a exploração dos requisitos do software / sistema que define a estratégia geral do projeto.

1. Iteração 0: Previsão

Existem duas sub ativações principais.

A. Previsão dos requisitos iniciais.

Pode levar vários dias para identificar os requisitos de alto nível e o escopo do sistema. O foco principal é explorar o modelo de uso, o modelo de domínio inicial e o modelo de interface do usuário (IU).

B. Visão inicial da arquitetura.

Também leva vários dias para identificar a arquitetura do sistema. Permite definir orientações técnicas para o projeto.

O foco principal é explorar diagramas de tecnologia, fluxo de interface do usuário (IU), modelos de domínio e casos de mudança.

2. Modelagem de iteração:

Aqui, a equipe deve planejar o trabalho que será feito para cada iteração.

  • O processo Agile é usado para cada iteração, ou seja, durante cada iteração, um novo item de trabalho será adicionado com prioridade.
  • O primeiro trabalho com maior prioridade será levado em consideração. Os itens de trabalho adicionados podem ser priorizados novamente ou removidos da pilha de itens a qualquer momento.
  • A equipe discute como vão implementar cada requisito. A modelagem é usada para esse propósito.
  • A análise e o design da modelagem são feitos para cada requisito que será implementado para aquela iteração.

3. Model storming:

Isso também é conhecido como Modelagem Just in time.

  • Aqui, a sessão de modelagem envolve uma equipe de 2/3 membros que discutem as questões em papel ou quadro branco.
  • Um membro da equipe pedirá a outro para modelar com eles. Esta sessão de modelagem levará aproximadamente 5 a 10 minutos. Onde os membros da equipe se reúnem para compartilhar o quadro branco / papel.
  • Eles exploram os problemas até não encontrarem a causa principal do problema. Bem a tempo, se um membro da equipe identificar o problema que deseja resolver, ele receberá ajuda rápida de outros membros da equipe.
  • Outros membros do grupo exploram a questão e todos continuam como antes. Também é chamado de modelagem stand-up ou sessões de controle de qualidade do cliente.

4. Desenvolvimento Orientado a Testes (TDD).

  • Ele promove testes de confirmação do código do aplicativo e especificações detalhadas.
  • Ambos os testes de aceitação (requisitos detalhados) e testes de desenvolvedor (teste de unidade) são entradas para TDD.
  • O TDD torna o código mais simples e claro. Ele permite que o desenvolvedor mantenha menos documentação.

5. Avaliações.

  • Isso é opcional. Inclui inspeções de código e revisões de modelo.
  • Isso pode ser feito para cada iteração ou para todo o projeto.
  • Esta é uma boa opção para dar feedback sobre o projeto.

TDD e AMDD e Scrum

TDD

AMDD

SCRUM

TDD encurta o ciclo de feedback de programaçãoAMDD encurta o ciclo de feedback de modelagem.Encurta o ciclo de feedback do andamento do projeto.
TDD é uma especificação detalhadaAMDD trabalha para problemas maioresScrum trabalha para projetos complexos e inovadores
TDD promove o desenvolvimento de código de alta qualidadeAMDD promove comunicação de alta qualidade com as partes interessadas e desenvolvedores.Scrum auxilia a equipe a manter um ritmo sustentável
TDD fala com programadoresAMDD conversa com analistas de negócios, partes interessadas e profissionais de dados.Scrum fala com todos os envolvidos
TDD não orientado visualmenteAMDD orientado visualmenteScrum orientado visualmente
TDD tem escopo limitado para trabalhos de softwareA AMDD tem um amplo escopo, incluindo partes interessadas. Envolve trabalhar para um entendimento comumScrum

tem um amplo escopo, incluindo partes interessadas. Envolve trabalhar para um entendimento comum

Apoia o desenvolvimento evolutivoApoia o desenvolvimento evolutivoApoia o desenvolvimento evolutivo

Vantagens e desvantagens do Modelo de Test-Driven Development (TDD):

Vantagens

  • Notificação de bug antecipada.

    Os desenvolvedores testam seu código, mas no mundo do banco de dados, isso geralmente consiste em testes manuais ou scripts únicos. Usando o TDD, você constrói, ao longo do tempo, um conjunto de testes automatizados que você e qualquer outro desenvolvedor pode executar novamente à vontade.

  • Código melhor projetado, mais limpo e mais extensível.
    • Ajuda a compreender como o código será usado e como ele interage com outros módulos.
    • Isso resulta em melhor decisão de design e código mais sustentável.
    • O TDD permite escrever códigos menores com responsabilidade única, em vez de procedimentos monolíticos com responsabilidades múltiplas. Isso torna o código mais simples de entender.
    • O TDD também força a escrever apenas o código de produção para passar nos testes com base nos requisitos do usuário.
  • Confiança para Refatorar
    • Se você refatorar o código, pode haver possibilidades de quebras no código. Portanto, tendo um conjunto de testes automatizados, você pode consertar essas quebras antes do lançamento. Um aviso adequado será fornecido se houver interrupções durante o uso de testes automatizados.
    • Usar o TDD deve resultar em um código mais rápido e extensível com menos bugs que podem ser atualizados com riscos mínimos.
  • Bom para trabalho em equipe

    Na ausência de qualquer membro da equipe, outros membros da equipe podem facilmente pegar e trabalhar no código. Também auxilia no compartilhamento de conhecimento, tornando a equipe mais eficaz em geral.

  • Bom para desenvolvedores

    Embora os desenvolvedores tenham que gastar mais tempo escrevendo casos de teste TDD, leva muito menos tempo para depurar e desenvolver novos recursos. Você escreverá um código mais limpo e menos complicado.

Um estudo de 2005 descobriu que usar TDD significava escrever mais testes, e logo, programadores que escreviam mais testes tendiam a ser mais produtivos.10

Hipóteses relacionando a qualidade de código e uma correlação direta entre TDD e produtividade foram inconclusivas.11

Desenvolvedores usando TDD puramente em novos projetos reportaram que raramente necessitaram a utilização de um depurador.13

Desenvolvimento dirigido por testes oferece mais do que somente um maneira simples de validação e de correção, pode orientar o design de um programa.

Por focar em casos de testes primeiramente, deve-se imaginar como a funcionalidade será usada pelo cliente.

Logo, o programador é somente com a interface e não com a implementação.

Este benefício é complementar ao Design por Contrato, que através torna os casos de testes muito mais do que asserções matemáticas ou preconcepções.

O poder que TDD oferece é a habilidade de pegar pequenas partes quando requeridas.

Isso permite o desenvolvedor focar como objetivo fazer os testes atuais passarem. Casos excepcionais e tratamento de erros não são considerados inicialmente.

Testes que criam estas circunstâncias estranhas são implementadas separadamente.

Outra vantagem é que TDD quando usado apropriadamente, garante que todo o código desenvolvido seja coberto por um teste.

Isto fornece a equipe de desenvolvimento, e ao usuários, subsequentemente, um grande nível de confiança ao código.

Enquanto que é verdade que mais código é necessário ao usar TDD do que sem TDD, devido aos códigos de teste, o tempo total de implementação é tipicamente menor.14 Um grande número de testes ajudam a limitar o número de defeitos no código.

A natureza periódica ajuda a capturar defeitos inicialmente no ciclo de desenvolvimento, prevenindo-os de se tornarem grandes e endêmicos problemas.

Eliminando defeitos cedo no processo normalmente evita longos e entediantes períodos de depuração posteriores em um projeto.

TDD pode encaminhar a um nível que possibilite um código mais modularizado, flexível e extensível. Este efeito surge devido a metodologia requerer que os desenvolvedores pensem no software em pequenas unidades que podem ser reescritas, desenvolvidas e testadas independentemente e integradas depois.

Isto implica menores e mais classes, evitando o acoplamento e permitindo interfaces mais limpas.

O uso de Mock Object é um contribuidor para a modularização do código, pois este recurso requer que o código seja escrito de forma que possa ser facilmente trocado entre versões Mock, usados em testes de unidade, e “reais”, usados na aplicação.

Devido a fato de que nenhum código é escrito a não ser para passar em um teste que esteja falhando, testes automatizados tendem a cobrir cada caminho de código.

Por exemplo, para que um desenvolvedor possa adicionar um caminho alternativo “senão” em um “se” , o desenvolvedor poderia primeiramente escrever um teste que motive o fluxo alternativo.

Como resultado, os testes automatizados TDD tendem a ser mais perfeitos: eles irão mostrar qualquer mudança inesperada no comportamento do código.

Isto ajuda a identificar problemas cedo que poderiam aparecer ao consertar uma funcionalidade que ao modificada, inesperadamente altera outra funcionalidade.

Desvantagens

  1. Desenvolvimento dirigido com testes é difícil de usar em situações onde testes totalmente funcionais são requeridos para determinar o sucesso ou falha.
    Exemplos disso são interfaces de usuários, programas que trabalham com base de dados, e muitos outros que dependem de configurações específicas de rede.
    TDD encoraja os desenvolvedores a incluir o mínimo de código funcional em módulos e maximizar a lógica, que é extraída em código de teste, usando Fakes mocks para representar o mundo externo.
  2. Suporte gerencial é essencial. Se toda a organização não acreditar que TDD é para melhorar o produto, o gerenciamento irá considerar que o tempo gasto escrevendo teste é desperdício.15
  3. Os próprios testes se tornam parte da manutenção do projeto. Testes mal escritos, por exemplo, que incluem strings de erro embutidas ou aqueles que são susceptíveis a falha, são caros de manter. Há um risco em testes que geram falsas falhas de tenderem a serem ignorados.
    Assim quando uma falha real ocorre, ela pode não ser detectada. É possível escrever testes de baixa e fácil manutenção, por exemplo pelo reuso das strings de erro, podendo ser o objetivo durante a fase de refatoração descrita acima.
  4. O nível de cobertura e detalhamento de teste alcançado durante repetitivos ciclos de TDD não pode ser facilmente recriado em uma data tardia. Com o passar do tempo os testes vão se tornando gradativamente preciosos. Se uma arquitetura pobre, um mal design ou uma estratégia de teste mal feita acarretar em mudança tardia, fazendo com que dezenas de testes falhem, por outro lado eles são individualmente consertáveis. Entretanto, simplesmente deletando, desabilitando ou alterando-os vagamente poderá criar buracos indetectáveis na cobertura de testes.
  5. Lacunas inesperadas na cobertura de teste podem existir ou ocorrer por uma série de razões. Talvez um ou mais desenvolvedores em uma equipe não foram submetidos ao uso de TDD e não escrevem testes apropriadamente, talvez muitos conjuntos de testes foram invalidados, excluídos ou desabilitados acidentalmente ou com o intuito de melhorá-los posteriormente.
    Se isso acontece, a certeza é de que um enorme conjunto de testes TDD serão corrigidos tardiamente e refatorações serão mal acopladas. Alterações podem ser feitas não resultando em falhas, entretanto, na verdade, bugs estão sendo introduzidos imperceptivelmente, permanecendo indetectáveis.
  6. Testes de unidade criados em um ambiente de desenvolvimento dirigido por testes são tipicamente criados pelo desenvolvedor que irá então escrever o código que está sendo testado. Os testes podem consequentemente compartilhar os ‘pontos cegos’ no código: Se por exemplo, um desenvolvedor não realizar determinadas entradas de parâmetros que precisam ser checadas, muito provavelmente nem o teste nem o código irá verificar essas entradas.
    Logo, se o desenvolvedor interpreta mal a especificação dos requisitos para o módulo que está sendo desenvolvido, tanto os testes como o código estarão errados.
  7. O alto número de testes de unidades pode trazer um falso senso de segurança, resultando em menor nível de atividades de garantia de qualidade, como testes de integração e aceitação.

Conclusão

TDD significa desenvolvimento dirigido por testes. É um processo de modificação do código para passar em um teste desenvolvido anteriormente.

É mais ênfase no código de produção do que no design do caso de teste.

O desenvolvimento orientado a testes é um processo de modificação do código para passar em um teste projetado anteriormente.

Em Engenharia de Software, às vezes é conhecido como “Teste Primeiro o Desenvolvimento”.

TDD inclui refatorar um código, ou seja, alterar / adicionar alguma quantidade de código ao código existente sem afetar o comportamento do código.

TDD quando usado, o código se torna mais claro e simples de entender.

Referências

  1. Sérieda Projetos e TI – Agile Methods
  2. Beck, K. Test-Driven Development by Example, Addison Wesley – Vaseem, 2003
  3. Newkirk, JW and Vorontsov, AA. Test-Driven Development in Microsoft .NET, Microsoft Press, 2004.
  4. Feathers, M. Working Effectively with Legacy Code, Prentice Hall, 2004
  5. Hossein Saiedian – Simulação Orientada a Objetos do protocolo CSMA
  6. Beck, Kent (08/11/2002). Desenvolvimento orientado a testes por exemplo. Vaso: Addison Wesley. ISBN 978-0-321-14653-3.
  7. Beck, Kent (1999). XP Explicado, 1ª Edição.
  8. Addison-Wesley Professional. p. 57 . ISBN 0201616416.
  9. Newkirk, JW e Vorontsov, AA. Desenvolvimento Orientado a Testes em Microsoft .NET , Microsoft Press, 2004.
  10. Erdogmus, Hakan; Morisio, Torchiano. «On the Effectiveness of Test-first Approach to Programming». Proceedings of the IEEE Transactions on Software Engineering, 31(1). January 2005. (NRC 47445). Arquivado do original em 27 de agosto de 2011. We found that test-first students on average wrote more tests and, in turn, students who wrote more tests tended to be more productive.”
  11. Proffitt, Jacob. «TDD Proven Effective! Or is it?». Arquivado do original em 27 de agosto de 2011. “So TDD’s relationship to quality is problematic at best. Its relationship to productivity is more interesting. I hope there’s a follow-up study because the productivity numbers simply don’t add up very well to me. There is an undeniable correlation between productivity and the number of tests, but that correlation is actually stronger in the non-TDD group (which had a single outlier compared to roughly half of the TDD group being outside the 95% band).”
  12. Clark, Mike. «Test-Driven Development with JUnit Workshop». Clarkware Consulting, Inc. In fact, test-driven development actually helps you meet your deadlines by eliminating debugging time, minimizing design speculation and re-work, and reducing the cost and fear of changing working code.”[/note] Usado em junção com um Sistema de controle de versão, quando testes falham inesperadamente, reverter o código para a última versão em que os testes passaram pode ser mais produtivo do que depurar.12Llopis, Noel (20 de fevereiro de 2005). «Stepping Through the Looking Glass: Test-Driven Game Development (Part 1)». Games from Within. Arquivado do original em 13 de outubro de 2007. “Comparing [TDD] to the non-test-driven development approach, you’re replacing all the mental checking and debugger stepping with code that verifies that your program does exactly what you intended it to do.”
  13. Müller, Matthias M.; Padberg, Frank. «About the Return on Investment of Test-Driven Development» (PDF). Universität Karlsruhe, Germany. 6 páginas.
  14. Loughran, Steve (November 6th, 2006). «Testing» (PDF). HP Laboratories.
Tags:, , , , , , ,

Leave a Reply