_20100519011102.gif)
Minha primeira Experiência TDD
olá Pessoal,
No post de hoje é compartilhar com vocês minha primeira experiência com TDD de forma mais corporativa onde tinha que entregar algo de fato(e sair dos tests made in house).Para quem acompanha o blog, meu twitter sabe que venho estudando e se envolvendo cada dia com o mundo Agile. Como toda primeira experiência nunca sabemos como será o resultado,uma vez que não nada de background para aquele contexto. Talvez podemos falhar ou ter um sucesso do tipo “aceito”. E para sabermos disso precisamos apenas de coragem(não esqueça dessa palavra quando tiver trabalhando com TDD) e deixar o medo de errar de lado. Foi assim, que começei meus “baby-steps” com TDD. O que aprendi de cara foi: “uma coisa é usar TDD em seus projetos pessoais at home, e outro quando vamos para complexidade que temos no mundo de um negócio real, são experiências muito distante, porém se não tivesse feito aquela experiência caseira, o impacto seria maior”.
Vamos ver o que rolou…
lets go…
Cenário
Surgiu uma nova feature no projeto e teremos que implementar, e daí cai isso na minha mesa(sempre acontece isso no desenvolvimento de software certo?). O escopo, design, desenvolvimento etc. Tudo isso é responsabilidade do engenheiro/desenvolvedor/analista/arquitetos etc encontrar uma solução para a tal feature. Alguem precisa dela done no prazo X , dentro dos criterios de aceitação YXZ.
Minha Experiência
Normalmente um produto tem muitas features, no inicio gera uma pergunta: “Por onde começar?” “qual a melhor feature implementar por agora?” Selecionei a mais simples. Antes eu poderia ir logo na mais que aparentava difícil, mas com TDD eu precisava fazer de forma mais simples possível, desde que saisse do vermelho para verde. Daí começei a criar os units tests para uma determinada classe, pensando nos problemas, principalmente aqueles esperados, as exceções que deveriam acontecer quando o contexto fosse ZX. E foi assim que começei, da maneira mais simples e “boba”, a medida que ia adicionando novas features e o código mudando, os tests mais simples failure e isso era bom, porque sabia que uma nova feature que foi implementada, fez meu código quebrar e eu fiquei sabendo disso o quanto antes e agora devo fixar para poder ir adiante. Então esses feedbacks rapidos foram cruciais, pois não esperei até o deploy acontecer e o pessoal de QA abrir um bug 
Para saber o que precisava ser feito, fiz um BillBoard, com as tasks(to-do), o que está sendo feito(in progress), e o que foi feito – Done (faltou uma coluna com blocker). Assim podemos manter o foco e saber de fato do que estamos fazendo e ajuda até dar um bom status nas scrums com o team.
O resultado
Resultado veio além do esperado, no inicio gastei bastante tempo com o units tests e seguindo os conceitos da metodologia, porém ganhei mais velocidade lá na frente e principalmente na semana final, pois tinhamos code clear(TDD ajudou identificar onde deveria refatorar), units tests fazendo boa cobertura e testes rápidos.
A moral da história que ganhei 2 dias free, pois conseguir entregar antes do deadline, com um bom tempo sobrando para fazer qualquer coisa, e o melhor de tudo a segurança que os criterios de aceitação daquela feature estava sendo alcançada com o menor esforço possível(não foi necessário dar aquelas esticadas de 2-3 hrs após o expediente). Então feature accepted, good cobertura de code e code clear. Tudo provocado por algo chamado TDD. Observem que nada disso foi planejado, era apenas entregar a feature, mas por consequência do destino, TDD trouxe vários outros beneficios de forma indireta ao desenvolvimento.
TDD não é a solução para todos os problemas que temos no desenvolvimento de software, não passa de uma metodologia que depende como está sendo aplicada ao projeto, e o mais importante pessoas etc. Se as pessoas envolvidas não estão nem ai, e não acreditam já entramos perdendo no jogo.
Eu faço uma associação bem abstrata para quem não entende TDD com aquelas metodologias que aprendemos na faculdade de como fazer o seu TCC, sabemos que só a metodologia não vai fazer o seu TCC, você vai precisar entender do assunto que deseja escrever, e começar a usar a metodologia para ti guiar como terminar aquilo da melhor forma possível e saber quando acabou ou quanto falta para acabar. E o melhor se vai dar tempo de entregar dentro do prazo (basta olhar o seu burn down chart do TCC rs).
Um livro que eu deveria ter lido, antes de ir para minha primeira experiência profissional com TDD era o do Kent Beck, mas não tive tempo, pois foi um challenge que surgiu em questão de poucos dias e daí tive que usar os materiais que já tinha em mãos e li bastante artigos, post da galera mais expert: Guilherme Silveira, Philip Calçado, Rodrigo Yoshima, Guilherme Chapiewski há alguns post e palestras legais no InfoQ. E o que não deu pra ver ler, teve que ser visto na pratica com erros e acertos.
Vou ficando por aqui, e espero que tenham gostado do post, não deixe de compartilhar como foi sua primeira experiência com TDD, ficaria feliz em ler outros cases. O objetivo do post, é mostrar para aqueles que estão na dúvida do uso de TDD, para saber de fato se funciona, tem que colocar mão na massa, o máximo que você vai descobrir no final é que TDD não atendeu aquele contexto que você tentou validar.
Abracos, see ya!!
