Desenvolvimento Orientado por Testes

A metodologia “eXtreme Programming” promove o desenvolvimento orientado por testes (TDD). O quer isto dizer?

Contrariamente ao que a técnica do TDD aconselha, não é pouco-comum encontrar um programador que “ataca de cabeça” o desenvolvimento de uma qualquer funcionalidade.

Síndrome do cobertor curto

“Não vejo o mal nisso” poderás estar a pensar. Deixa-me então colocar a seguinte questão – já te aconteceu implementar/actualizar/corrigir uma funcionalidade e por obras de magia negra, outra funcionalidade “completamente ao lado” partiu? A isto se poderia chamar de síndrome do cobertor curto. Para taparmos de um lado, vamos destapar noutro.

test-driven development diagramO XP aconselha o desenvolvimento em ciclos curtos e em constante repetição. O programador deverá criar um teste e executá-lo. Este deverá falhar pois ainda não temos código real para ser testado. É só então que o código para a funcionalidade é criado e volta-se a executar o teste. Quando o teste passar o programador deverá, sem qualquer demora, revisitar o código escrito e refactorizá-lo. Este é o ciclo curto de desenvolvimento do XP.

Existem vários tipos de testes – unitários, integração, funcionais e aceitação. Todos eles, como iremos ver, são de especial importância no ciclo de vida do software.

Testes Unitários

Este tipo de teste, tal como o nome indica, deverá testar uma unidade de código. Tipicamente testará cada método público, em particular e sem qualquer tipo de contacto com o resto do sistema. Idealmente o que se testará é a correcta entrada e retorno de dados. Se eventualmente numa iteração futura, um programador alterar o comportamento desse método para aceitar ou retornar outro tipo de dados, o teste deverá automaticamente falhar.

É bastante comum se encontrar programadores a desenvolver na técnica – “testes orientados ao código”. É de primordial importância o desenvolvimento primeiro dos testes e somente depois o algoritmo. Fazer o processo inverso fará com que o código seja muito mais difícil de testar.

É interessante salientar que este tipo de testes, quando bem estruturados, também poderão servir como documentação do sistema. Quantos testes unitários se deve escrever por sistema? Bom, de acordo com o Robert “Uncle Bob” Martin, dever-se-á abranger 100% de todo o código !!!

Testes de Integração

Após a realização de testes unitários, onde se testaram unidades isoladas do sistema, é a altura de se misturar as peças. Existem várias aproximações a este tipo de teste – “big-bang”, “top-down”, “bottom-up”, “mixed” e “risky-hardest”. Deixarei a explicação destas abordagens para futuros artigos. No entanto, e se com os testes unitários se defende a cobertura de 100% do código, com estes testes a situação merece uma maior reflexão. O J.B.Rainsberger explicou como se poderá estar a criar um pequeno Monstro ao se utilizar testes de integração, pois facilmente se poderão chegar a milhares de testes. Aconselho a verem a apresentação (ou lerem o artigo) do Rainsberger.

Testes Funcionais

Os testes funcionais fazem parte do processo de Controlo de Qualidade (QA). Como o nome permite adivinhar, num teste funcional ir-se-á testar uma funcionalidade, de acordo com a especificação e requerimentos do sistema. O funcionamento interno não é tido em consideração, daí a designação de teste “caixa-negra”. Também estes testes têm várias abordagens.

Testes de Aceitação

Poderemos considerar a fase de testes de aceitação como o último momento para a libertação de um sistema de software. Estes são escritos a partir de “user stories” definidas pelo cliente. Um exemplo de um teste de aceitação num sistema de backend poderia ser:

  • o utilizador acede à página de login
  • o utilizador insere dados de autenticação (user: admin, pass: password)
  • o utilizador é reencaminhado para a página X

Basicamente ir-se-á testar possíveis cenários, mimicando utilizadores reais. Como estamos numa fase de pré-lançamento, o cliente e a equipa de QA deverão estar em uníssono sobre o que é pretendido testar.

 

Todos estes testes deverão ser automatizados e, de acordo com outro princípio do XP, deverão correr em contínua integração do código. Não te preocupes com este conceito, um artigo sobre o mesmo já está na calha.

Ficaste convencido que programar com recurso a testes é vantajoso? Partilha a tua opinião.