•Test-Driven Development (TDD) é uma metodologia que utiliza os testes para auxiliar os desenvolvedores tomar as decisões certas na hora certa. TDD não é somente testes, É sobre utilizar os testes para desenvolver software de uma maneira simples e incremental. Não somente maximiza a qualidade e o design do software, como também simplifica o processo de desenvolvimento.
A beleza do TDD é que com pequenas mudanças na sua metodologia de desenvolvimento a algumas ferramentas adicionais o desenvolvedor é capaz de produzir software de maneira rápida e veloz.
TDD é uma das práticas do Extreme Programming (XP).As práticas do XP foram formuladas por Kent Beck e Ron Jeffries a partir de suas experiências no desenvolvimento de uma sistema de pagamento para a Chrysler. As idéias gerais por trás do XP são simplificar o processo de desenvolvimento simples e manter um processo contínuo de desenvolvimento em um ciclo curto que fornece um feedback constante do estado do software. As idéias do TDD tem ganho uma grande aceitação nos meio dos desenvolvimento e projetos de software.
A Metodologia do Test-Driven Development
TDD é uma metodologia muito simples que se resume em dois conceitos:
Testes unitários e refatoração.
TDD é basicamente composto nos seguintes passos:
–Escrever um teste que define como você acha que pequeno pedaço da aplicação deveria se comportar.
–Fazer o teste rodar da maneira mais fácil e rápida que você pode. Não se preocupe com a qualidade do código, apenas faça funcionar.
–Enxugue o código. Agora que o código esta funcionando corretamente, dê um passo para trás e refatore para remover qualquer duplicação ou qualquer outro problema que foi apresentado para tornar o teste executável.
TDD é um processo iterativo e você repete estes passos inúmeras vezes até que você fique satisfeito com o novo código.
A maneira que TDD trabalha é através de requisitos, ou casos de uso que são decompostos em um conjunto de comportamentos que são premissa para atender o requisito.
Para cada comportamento do sistema, a primeira coisa a se fazer é escrever um teste unitário que irá testar este comportamento. O teste unitário primeiro portanto temos um conjunto bem definido de critérios que podemos utilizar para mensurar a quantidade de código necessário que foi escrito para implementar este comportamento. Um dos beneficios de se escrever o teste primeiro é que ele ajuda a definir o comportamento do sistema de uma maneira mais clara e responder algumas perguntas do modelo.
Convencendo as pessoas a utilizar TDD
Desenvolver software é um risco assumido. É quase impossível entregar um projeto dentro do orçamento e do prazo. De acordo com um estudo da Gartner Group, 30% dos projetos falham e não chegam aos seus objetivos, e 70% são entregues em atraso ou fora do orçamento previso. Claramente existe a necessidade de melhorar este processo, mas a questão é como. TDD pode ser parte da resposta, mas antes de convencer as pessoas a utilizar TDD é preciso entender e apresentar os problemas do processo atual. Uma vez entendido as falhas do processo corrente, é preciso entender como utilizar TDD para suprir estas falhas e utilizar este conhecimento para convencer as outras pessoas que isso irá funcionar.
Encontrando as falhas no processo corrente.
O processo mais usual quando não se pratica TDD é o famoso modelo cascata (análise dos requisitos, modelo, código e o teste). A maioria dos problemas relacionados ao desenvolvimento de software é má comunicação da equipe e uma execução falha. Para entender as falhas do processo corrente, devemos responder algumas perguntas básicas como:
–Qual é a maior causa dos bugs no softwares ?
–Qual é a maor causa dos atrasos no cronograma ?
–Qual é a média de bugs a cada 1000 linhas de código escrito ?
–Como o processo reage a uma mudança de requisito.
–Qual a fase do projeto que mais tenho problemas ? (Desing, código, integração, etc..)
Uma vez que estas perguntas foram respondidas, é provável que você tenha uma idéia melhor dos problemas no processo corrente. É muito importante entender estas questões antes de entender como e se o TDD pode ser utilizado para resolver os problemas.
A beleza do TDD é que com pequenas mudanças na sua metodologia de desenvolvimento a algumas ferramentas adicionais o desenvolvedor é capaz de produzir software de maneira rápida e veloz.
TDD é uma das práticas do Extreme Programming (XP).As práticas do XP foram formuladas por Kent Beck e Ron Jeffries a partir de suas experiências no desenvolvimento de uma sistema de pagamento para a Chrysler. As idéias gerais por trás do XP são simplificar o processo de desenvolvimento simples e manter um processo contínuo de desenvolvimento em um ciclo curto que fornece um feedback constante do estado do software. As idéias do TDD tem ganho uma grande aceitação nos meio dos desenvolvimento e projetos de software.
A Metodologia do Test-Driven Development
TDD é uma metodologia muito simples que se resume em dois conceitos:
Testes unitários e refatoração.
TDD é basicamente composto nos seguintes passos:
–Escrever um teste que define como você acha que pequeno pedaço da aplicação deveria se comportar.
–Fazer o teste rodar da maneira mais fácil e rápida que você pode. Não se preocupe com a qualidade do código, apenas faça funcionar.
–Enxugue o código. Agora que o código esta funcionando corretamente, dê um passo para trás e refatore para remover qualquer duplicação ou qualquer outro problema que foi apresentado para tornar o teste executável.
TDD é um processo iterativo e você repete estes passos inúmeras vezes até que você fique satisfeito com o novo código.
A maneira que TDD trabalha é através de requisitos, ou casos de uso que são decompostos em um conjunto de comportamentos que são premissa para atender o requisito.
Para cada comportamento do sistema, a primeira coisa a se fazer é escrever um teste unitário que irá testar este comportamento. O teste unitário primeiro portanto temos um conjunto bem definido de critérios que podemos utilizar para mensurar a quantidade de código necessário que foi escrito para implementar este comportamento. Um dos beneficios de se escrever o teste primeiro é que ele ajuda a definir o comportamento do sistema de uma maneira mais clara e responder algumas perguntas do modelo.
Convencendo as pessoas a utilizar TDD
Desenvolver software é um risco assumido. É quase impossível entregar um projeto dentro do orçamento e do prazo. De acordo com um estudo da Gartner Group, 30% dos projetos falham e não chegam aos seus objetivos, e 70% são entregues em atraso ou fora do orçamento previso. Claramente existe a necessidade de melhorar este processo, mas a questão é como. TDD pode ser parte da resposta, mas antes de convencer as pessoas a utilizar TDD é preciso entender e apresentar os problemas do processo atual. Uma vez entendido as falhas do processo corrente, é preciso entender como utilizar TDD para suprir estas falhas e utilizar este conhecimento para convencer as outras pessoas que isso irá funcionar.
Encontrando as falhas no processo corrente.
O processo mais usual quando não se pratica TDD é o famoso modelo cascata (análise dos requisitos, modelo, código e o teste). A maioria dos problemas relacionados ao desenvolvimento de software é má comunicação da equipe e uma execução falha. Para entender as falhas do processo corrente, devemos responder algumas perguntas básicas como:
–Qual é a maior causa dos bugs no softwares ?
–Qual é a maor causa dos atrasos no cronograma ?
–Qual é a média de bugs a cada 1000 linhas de código escrito ?
–Como o processo reage a uma mudança de requisito.
–Qual a fase do projeto que mais tenho problemas ? (Desing, código, integração, etc..)
Uma vez que estas perguntas foram respondidas, é provável que você tenha uma idéia melhor dos problemas no processo corrente. É muito importante entender estas questões antes de entender como e se o TDD pode ser utilizado para resolver os problemas.
Postagens
2 comentários:
Exelente seu artigo, sem duvida uma coisa simples que explica o que é TDD como funciona parabéns, voce conhece alguns caimhos para aprofundamento?
Olá Inácio, me desculpe a demora por responder, fiquei um bom tempo sem acessar o meu blog.
Bom para você se aprofundar no assunto eu recomendo você ler um livro sobre eXtreme Programming (procure por XP explained do Kent Beck), e depois se você quiser se aprofundar em TDD eu sugiro o livro que esta nas minhas recomendações (TDD and Acceptance TDD for Java Developers).
Boa Leitura, qualquer coisa estamos aí...
Postar um comentário