Pular para o conteúdo

Extreme Programming e sua relação com Software Livre

Uma análise de como a metodologia de desenvolvimento ágil de software pode ajudar a divulgação do software livre.
Alexandre Felipe Muller de Souza winchester
Hits: 25.101 Categoria: Linux Subcategoria: Miscelânea
  • Indicar
  • Impressora
  • Denunciar

Parte 3: Desenvolvimento orientado a testes

Nada é liberado sem ser testado. Por isso deve-se testar um pouco e desenvolver um pouco. Esta é a idéia que rege o ciclo de desenvolvimento. Cada funcionalidade antes de ser implementada é expressa por um script de testes. O desenvolvimento é feito pensando em cumprir este script. Os test case são escritos com as mais variadas possibilidades que cumprem uma tarefa. O código só pode ser considerado pronto se obedecer a todos os test cases.

Os testes não são aplicáveis somente no programa final. Nem aos executáveis propriamente dito, são aplicáveis as linhas de código também. Você pode fazer especificação de testes pra uma função por exemplo. Aí entra os unit tests.

A idéia é testar a funcionalidade de cada bloco do seu programa. Blocos pequenos ou grandes. E depois você testa no resultado final a integração entre essas unidades.

Testes automatizados

Este tipo de desenvolvimento gera tantos casos de teste que se torna inviável executá-los por uma pessoa. Então passa a ser necessário automatizar os testes. Vale de tudo, macros, escrever mais programas, scripting, expressões regulares.

Aí o software livre tem uma diferença crucial. É mais fácil automatizar testes conhecendo suas ferramentas a usar ferramentas as quais você não tem acesso do seu funcionamento. Geralmente programas escritos em software livre são módulos inter-conectados de maneira que você conhece todos os níveis que formam a ligação com o hardware. O exemplo é básico, melhor automatizar uma tarefa usando Script Shell ou usando DOS!?

Os testes automatizados formam uma suíte de testes que são executados rotineiramente. Cada bug e funcionalidade deve ter um script de testes que a definem. Estes testes devem ser executados posteriormente com freqüência para poder detectar bugs reabertos e funcionalidades quebradas.

   1. O que é XP, o que se propõe?
   2. Desenvolver de trás pra frente?
   3. Desenvolvimento orientado a testes
   4. Programação coletiva (pair programming)
   5. Porque este artigo

Porque Linux não emplaca em desktops

Jopen, não se preocupe mais em descobrir qual aplicativo usar

MultiHeads no Linux

Solução corporativa Expresso Livre, substituto de peso do Notes

Como montar um pacote RPM

Instalação do Fedora Workstation 33

Storj - Armazenamento na Nuvem utilizando a tecnologia Blockchain

Burg - Gerenciador de Boot

Instalando Debian direto do HD

Já falamos do PC Popular, mas será que o laptop também é ruim?

#1 Comentário enviado por InFog em 28/08/2007 - 09:57h
Cara eu gostei muito desse artigo, esse negócio de XP é muito legal =) Essa parte de Programação em Duplas deve muito eficaz, tanto para evitar a perda de foco como para a auditoria em tempo real.

InFog
#2 Comentário enviado por michel.peloso em 28/08/2007 - 13:03h
Cara, achei muito legal o seu artigo.. achei ele bem produtivo..
Continue assim..
Falau..
#3 Comentário enviado por hiroyuki em 28/08/2007 - 19:00h
Bacana o artigo, interessante, vou dar uma lida em mais coisas =)
#4 Comentário enviado por argentino_nsi em 28/08/2007 - 19:57h
Bom o artigo. Porém, por que todo mundo sempre compara o XP com Análise Essencial?
Não estou dizendo que uma metodologia de desenvolvimento é melhor que outra, mas a impressão que passa, é que quem defende o XP, ou não conhece ou não entendeu o ciclo Iterativo e incremental do Processo Unificado.

abraços
#5 Comentário enviado por TSM em 28/08/2007 - 20:37h
Parabéns pelo artigo, muito bom mesmo, e essa metodologia é muita bacana, vou pesquisar mais sobre ela.

Valeu
Um abraço

Contribuir com comentário

Entre na sua conta para comentar.