Cada vez mais estamos buscando maneiras de melhorar a qualidade do software que produzimos, gerando um código com menos bugs e um produto final que gere valor para o cliente. Uma das melhores maneiras para se desenvolver software é praticar TDD, não só por escrever o teste primeiro, mais por contribuir significativamente para a melhoria do design do código, com classes mais coesas e com poucas responsabilidades, consequentemente, temos classes mais fáceis de testar e menos suscetíveis a falhas, e ainda por cima ganhamos uma especificação testável de brinde. :P
Estes testes tem também um papel fundamental garantindo que não haja regressão do software, ou seja, quando alguém altera o código, os testes devem continuar passando, garantindo que tudo continua funcionando adequadamente. Então antes de cada commit, precisamos fazer update no svn para atualizar nossa working copy, rodar os testes e deixar tudo verdinho e só depois integrar nossas alterações. Mais há algo errado com essa sequência de passos. É muito manual. Depende do desenvolvedor. Há muitos pontos de falha, ele pode esquecer de sincronizar seu repositório local, pode esquecer de rodar os testes, pode estar trabalhando até tarde e estar cansado demais pra rodar os teste, etc, etc. E o que devemos fazer então? Automatizar, é claro.
Vou mostrar em uma série de posts como construir um ambiente para aplicar na prática Integração Contínua. Claro que integração contínua não é apenas sobre ferramentas, é também uma mudança de comportamento, tem que ser incorporado à cultura do time, mais uma coisa de cada vez. Vamos ver a definição dada por Martin Fowler:
"Integração contínua é uma prática de desenvolvimento de software onde os membros de uma equipe integram seu trabalho frequentemente, geralmente cada um integra no mínimo diariamente – levando a múltiplas integrações por dia. Cada integração é verificada por um build automático (incluindo testes) para detectar erros de integração tão rápido quanto possível. Muitas equipes descobrem que esta prática leva a problemas de integração significativamente reduzidos e permite que a equipe desenvolva software coeso mais rapidamente."
Para colocar isso em prática utilizare-mos o Hudson como servidor de integração, Visual SVN Server como sistema de controle de código fonte, DUnit para testes unitários e delphi-code-coverage para cobertura de código.
Fique atento às próximas publicações.
Nenhum comentário:
Postar um comentário