O caos!
Já abordamos em alguns tópicos algumas dicas para fugir desse tormento que persegue um grande número de desenvolvedores espalhados pelo mundo. Mas em tempos de crise econômica e “apagão técnico”, somos expostos à diversas situações em que a sanidade vira uma vaga lembrança.
Imagem via Shutterstock
Test first
Metodologias ágeis como o Scrum e o XP adotam a técnica “Test First”:
- Primeiro escreva um teste que falhe
- Depois escreva um código que faça o teste passar
- Melhore o código escrito
Além da garantia de que sua aplicação irá funcionar após uma atualização ou bugfix, devemos levar em conta que estamos indo além do simples ato de testar. É nisso que muita gente se confunde quando fala-se em Test-Driven Development: Não trata-se apenas de testes, trata-se de design!
Os testes passam a ser a sua especificação, passam a ser a forma de você medir se o seu software está sendo conduzido para o real objetivo ou não. Literalmente, os testes guiam o seu desenvolvimento – mas isso não garante que a solução como um todo esteja funcional, por isso é necessário uma pitada de bom senso (como em tudo na vida).
Quando você menos espera, a construção dos testes automatizados passou de “testes” para “desenvolvimento”. Ou seja, esse método irá fazer parte do processo de construção de código e você começará a medir qualquer estimativa referente a codificação com os testes inclusos, naturalmente.
A Web está repleta de artigos sobre como construir estes testes, como executá-los, etc. Então, não vou ficar repetindo o que já foi “dito” e vou deixar referências de pessoas mais “conhecidas” do assunto:
- Vinicius Quaiato: TDD – Test Driven Development – http://viniciusquaiato.com/blog/index.php/tdd-test-driven-development-c/
- Coding Dojo Floripa: Tudo sobre TDD – http://dojofloripa.wordpress.com/2007/09/10/tudo-sobre-tdd/
- Improve It: Desenvolvimento Orientado a Testes – http://improveit.com.br/xp/praticas/tdd
- Agile Testing: Articles and Tutorials – http://agilistas.org/articles/
- Python Brasil: Test Driven Development – http://www.python.org.br/wiki/TestDrivenDevelopment
- Django Testing.com – http://djangotesting.com/
Automatizar = Agilidade?
Mas porque TDD ajuda tanto? Será que vale a pena praticar?
Quando comecei a programar orientado a objetos, tinha em mente que aquilo era só curiosidade, que no modo estruturado estava muito bom e não via a real utilidade daquilo tudo. Claro, isso até ser completamente envolvido por O.O., e quando me dei conta não sabia mais viver sem ele.
Ainda não posso dizer o mesmo de TDD, mas algumas fontes na Web afirmam que não têm prazer em desenvolver sem os testes automatizados (caso do @andrewsmedina). Passou a ser uma necessidade… e digo a razão: A taxa de acerto é alta, a ocorrência de erros diminui, e você volta a ter “dignidade” e a valorizar suas produções.
Mesmo que você perca tempo não previsto no desenvolvimento, poupa tempo (espero eu que) previsto nos testes. No começo a performance do desenvolvedor cai significativamente… mas com o tempo irá tornar-se uma prática para dar maior segurança em relação a qualidade do seu software, e também dar maior segurança a você.
5 Comentários
Oi Klaus, só discordo em um ponto:
“No começo a performance do desenvolvedor cai significativamente…”
Na verdade eu não percebi essa queda. Afinal enquanto estamos desenvolvendo é comum perdermos vários minutos em debug, ao menos é assim aqui na empresa, e o debug demora muito, afinal nossas aplicações consomem diversos webservices e aplicações remoting.
O tempo gasto escrevendo testes é o tempo gasto com debug, porém o debug garante que algo funcionou uma vez, em um cenários específico. O testes são “eternos” e garantirão o funcionamento após futuras alterações e diferentes cenários.
Bom artigo!
@Vinicius
Desculpe a demora pelo feedback! Você tem razão, também percebo dessa forma… mas é interessante expor isso como uma perda, de qualquer forma, pois é isso que os teus superiores (que não entendem esses novos métodos de fazer software) vão achar.
Tenho uma dúvida. Quando se fala que ‘O tempo gasto escrevendo testes é o tempo gasto com debug’ que tipos de testes estão incluídos? Testes de Unidade e Teste de Aceitação ou apenas o teste de unidade.
Na empresa que trabalho estamos usando o BDD. Para cada funcionalidade de um sistema criamos estórias de testes com vários cenários e seus resultados esperados, depois iniciamos o desenvolvimento da funcionalidade. Para cada cenário é criado um teste de aceitação e depois a funcianlidade, além disso criamos os testes de unidade. O tempo gasto para desenvolver os testes de aceitação + teste de unidade + funcionalidade é 40% maior que o tempo gasto apenas desevolvendo + debug.
Estamos trabalhando de forma errada?
@Magno,
Falo por mim quando digo que não há “certo ou errado”. Há a melhor maneira para o seu projeto (sei que é clichê, mas é isso mesmo). Vou tentar apresentar o meu cenário…
Escrever estórias e prever cenários, na minha opinião, não deve ser encarado como “tempo de testes” mas sim como “tempo de análise”. Você está deixando explícito o desejo dos stakeholders e através de frameworks BDD, está garantindo que a sua aplicação não quebre esse contrato. Em um modelo cascata, por exemplo, você “perderia” esse tempo fazendo levantamentos de requisitos e casos de uso.
Reparei recentemente que muitos dos testes comportamentais que eu fazia através de frameworks BDD poderiam ser substituídos por testes funcionais (e testes de javascript). Logo, deixei de utilizar frameworks BDD mas não deixei de praticar o BDD. Isto simplificou a escrita dos testes, o que me deu maior agilidade na hora de atualizá-los quando necessário.
Desenvolver no modo “programa e debuga” pode até ser mais rápido em um primeiro momento. Mas, por exemplo, ninguém garante que depois de um refactoring ou da adição de alguma funcionalidade a sua aplicação vai continuar funcionando. Apenas você, sentando e “debugando” tudo de novo (está fazendo uma tarefa que poderia ser automatizada).
Agora imagine você trabalhando em um time com 9 pessoas. Quem vai garantir que o seu último commit não quebrou o trabalho de um dia inteiro do seu colega do lado? É nesses pontos que os testes automatizados lhe dão qualidade, agilidade (e tempo).
Sem falar que deixar os testes guiarem o design da sua aplicação é muito mais ágil e assertivo, do que ficar prevendo design com “codifica e debuga”.
Espero ter ajudado 🙂
Klaus,
realmente com a utilização do desenvolvimento guiado a teste a qualidade melhorou muito.
Minha preocupação é em relação ao tempo do projeto que aumentou em torno de 40%, pois nenhum artefato que já faziamos antes deixaram de ser desenvolvidos, com Documento de Visão, Caso de Uso, especificação de Tela, Caso de Teste… Apenas incluimos o BDD.
Obrigada,