Artigo Clube Delphi 78 - Desenvolvimento Ágil e Seguro com Test-Driven Development

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

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.

 

Esse artigo faz parte da revista Clube Delphi Edição 78. Clique aqui para ler todos os artigos desta edição


Testes

Desenvolvimento Ágil e Seguro com Test-Driven Development

 

Quem nunca ouviu falar em metodologias ágeis? Um assunto tão em moda certamente não pode ser deixado de lado por nenhum desenvolvedor que queira estar atualizado. Esse “jeito novo” de fabricar software ajuda 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 em ambientes Delphi.

 

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 "

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?