O conceito do TDD prega que antes do desenvolvimento de
qualquer algoritmo do seu sistema, seja efetuado uma carga de scripts de testes
unitários para garantir que a solução solicitada pela aplicação tenha sido de
fato implementada de forma a atender qualquer situação.
Nos sistemas tradicionais, e até por questões culturais, a
grande maioria dos profissionais responsáveis pelo desenvolvimento destes
algoritmos deixa para efetuar seus testes após o desenvolvimento da solução,
pior que isso algumas vez sem nem mesmo desenvolver os testes unitários, e
ainda pode piorar, em algumas ocasiões nem mesmo fazendo testes básicos e de
sintaxe, quebrando assim o build da aplicação.
Recentemente fui alocado em um grande projeto no qual tive
experiência com grande parte das situações que levantei acima. No inicio do
projeto a equipe num todo foi muito imatura, o ambiente e o projeto ao qual
estávamos inseridos possuía constante mudança as quais tínhamos que nos
adaptar, e isso resultou na não utilização desta pratica. Nesta ocasião após o
sistema pronto foi iniciado um refactoring que contou com a implementação de
testes para garantir a integridade do sistema durante o seu continuo ciclo de
vida e versionamento.
Após esta experiência estava entrando em outro projeto, este
de pequeno porte onde busquei estudar mais a fundo os conceitos do TDD e mudar
minha forma de desenvolver. Foi sensacional!
Eu não precisava mais fazer deploy, subir a aplicação,
simular aquela situação que tinha acabado de implementar, corrigir o erro, e
iniciar o processo de deploy/aplicação todo novamente. Tudo isso já tinha sido
feito antes mesmo de eu ter desenvolvido o algoritmo, e testado script a script
durante o deploy da aplicação.
Tivemos perdas significativas em tempo de desenvolvimento,
em especial nas primeiras semanas durante a adaptação porem o resultado valeu
cada minuto investido nesta pratica. As informações disponibilizadas pelo
sistema desenvolvido utilizando TDD são integras e muito precisas, e isso se da
ao fato de o desenvolvedor ser forçado a imaginar todas as possíveis entrada de
dados do seu método e em ambientes distintos antes de implementar a solução.
Isso faz com que não saiam testes ‘viciados’ do sistema, testes óbvios em que o
desenvolvedor se certificou de acertar o retorno.
Nenhum comentário:
Postar um comentário