da a compreender melhor os requisitos, estimar custos mais precisamente, garantir menos bugs etc. Na situação em que vivemos, estamos aprendendo vagarosamente a não prender-se tanto à programação de regras de negócio, mas olhando também para um fator muito importante a esse tipo de produto: a sua qualidade final. Clientes não querem mais ver apenas o produto pronto e implantado, querem ver seu sistema funcionando e sem erros. Erros esses que podem levar sua empresa a uma situação de caos e fazê-los despender muito mais tempo e outros recursos em manutenção. Mas como garantir que o sistema não terá erros? Veremos como o Test-Driven Development pode ajudar a diminuir a quantidade de bugs e ainda mais: aumentar a confiança no código pelos programadores, melhorar a qualidade da modelagem do projeto e estimar prazos e custos com muito mais precisão. Como manipularemos código e nos basearemos fortemente em testes unitários, faremos uso do framework DUnit, uma ferramenta free e de código aberto, bastante utilizada Agile Development Gosto sempre de fazer uma analogia ao explicar metodologias ágeis. Nos primórdios das teorias da administração, um dos fundamentos básicos era a formalização. Todo e qualquer tipo de processo era formalizado (escrito) para que, posteriormente, se pudesse aprender com experiências passadas e entender como funciona a empresa. Com isso nasceu a burocracia. Algo relativamente bom se for seguido com disciplina, mas que pode atrapalhar e muito o andamento de uma organização. Hoje, vemos que o foco é realmente outro. A valorização nas pessoas é muito grande quando comparada a antigamente. A motivação do colaborador é muito importante para que tudo ocorra bem. Quebras na estrutura hierárquica das organizações também são práticas que vêm ganhando espaço para diminuir as barreiras à comunicação entre os funcionários. Se pararmos para analisar o desenvolvimento de software, algo muito mais novo veremos que a situação é muito semelhante. No início, não havia nenhuma forma de documentação. Após alguns anos, documentava-se tudo o que se podia especificar. Hoje, estamos vendo na prática que a documentação não deve ser o fim, mas o meio para chegarmos ao produto final. Por isso, metodologias ágeis vêm ganhando espaço ao lado de metodologias pesadas, fortemente baseadas em documentação como, por exemplo, o Unified Process, definido pelo RUP da empresa Rational. Outros motivos também levaram especialistas a pensar em processos mais ágeis na hora de desenvolver: Incompreensão nos requisitos, Mudança freqüente nos requisitos, Falta de planejamento, Mudança de equipe e Bugs e regressões freqüentes. Para resolver esses e outros problemas, celebridades na área, reuniram-se e escreveram o manifesto ágil, que define diversos pontos para eliminar barreiras ao desenvolvimento de software. Talvez a metodologia ágil mais comentada e utilizada hoje seja o eXtreme Programming, que define alguns pontos muito importantes e interessantes. Outras metodologias ágeis conhecidas são: Scrum, Crystal Clear, xUP, dX, MSF Agile etc. Qualidade no software Quando se fala em qualidade, logo temos em mente certificações ISO, CMMI etc. No entanto, esse tipo de controle de qualidade é aplicado basicamente aos processos utilizados, não ao produto final, que no caso é o sistema gerado. O que podemos observar hoje, no mundo do software, é uma enorme movimentação de empresas de grande porte para que seu produto final não contenha erros de programação. Com isso nasce um novo cargo muito bem visto atualmente: o de Quality Assurance (QA), que traduzido também significa Controle de Qualidade. Para se desenvolver um software é preciso levar em conta basicamente quatro quesitos: o tempo, os recursos (pessoal, financeiros etc.), os requisitos e a qualidade (Figura 1). Figura 1. Os quatro pilares no desenvolvimento de software Se um desses pilares é afetado, certamente afetará os outros. Por exemplo, se o tempo está muito curto para a entrega do projeto, teremos que aumentar os recursos, contratando um funcionário, ou diminuir os requisitos e funcionalidades a serem implementadas, ou, o que quase sempre acontece, aumentar a velocidade na programação, deixando diversos bugs não corrigidos e causando enormes problemas. Outra situação muito comum em um projeto é a seguinte: na hora da implantação do programa no cliente, muitos erros acontecem. O prazo quase sempre está estourado, ou quase lá, e o usuário continua pedindo novas funcionalidades, alterações de módulos existentes e correções. Isso leva a não testar o que é feito e podemos chegar facilmente a um ciclo vicioso (Figura 2). Figura 2. Ciclo vicioso de Kent Beck Se temos mais pressão, certamente construiremos menos testes ou fazê-los menos abrangentes. Quanto menos testes escrevermos, maior a probabilidade de introduzirmos erros na aplicação. Quanto mais erros a aplicação possuir, maior vai ser a pressão por parte do cliente para que os bugs sejam corrigidos e o sistema passe a funcionar perfeitamente. Ou seja, entramos em um ciclo muito comum e que se não for bem administrado pode levar um projeto a um estado de caos! Mas será possível não entrar em um ciclo evitando a tal situação de caos? A saída dada por Kent Beck em seu livro “Test-Driven Development: By Example” é muito simples: precisamos reverter a ordem. Quanto mais erros, mais testes devemos escrever. Quanto mais testes, menos bugs serão deixados no sistema. Com isso, o cliente fará menos pressão, o que nos deixará mais tranqüilos para codificar. Existem diversos tipos de testes de software executados por testers e equipes de QA nas empresas. Os mais utilizados e importantes são: Testes Unitários, Testes de Aceitação e Funcionais e Testes de Performance, Carga e Stress. O Test-Driven Development Agora que tivemos uma boa base sobre metodologias ágeis, qualidade e testes podemos começar a entender o que é e porque foi criada a metodologia Test-Driven Development. Elaborada basicamente por Kent Beck e formalizada no livro “Test-Driven Development – By Example”, essa não é uma metodologia de testes, mas sim, de desenvolvimento de software que pode ser facilmente integrada a outras delas como o tão conhecido XP.
Quer ler esse conteúdo completo?
Tenha acesso completo
