O sistema de testes dos meus sonhos

O uso de testes no desenvolvimento de software já vem me acompanhando desde que trabalhei com Smalltalk na Objective Solutions. O sistema de testes que eles tinham lá chegava muito próximo do que eu idealizo para um sistema de testes.

Recentemente eu li o livro Test-Driven Development do Kent Beck e resolvi experimentar TDD de forma radical em um projeto pessoal em que estou desenvolvendo em Python. O meu sentimento geral sobre o uso de TDD é a de que estou programando num ritmo bem mais lento do que costumo ter mas com a certeza absoluta de que estou seguindo pelo caminho correto.

Como os detalhes de implementação desse projeto não estão muito claros em minha cabeça o uso de TDD está se mostrando ideal, mas não recomendo para o desenvolvimento de uma aplicação na qual você já tenha uma boa idéia de como implementar pois ela realmente ‘desacelera’ o seu ritmo. Mas atenção: estou desaconselhando o uso de TDD e não a criação de testes! Nos projetos onde é possível desenvolver testes é fundamental fazê-lo.

Mas voltando ao assunto deste post eu adoraria ver uma ferramenta para Python com as seguintes funcionalidades:

  1. Suportar testes escritos com xUnit (unittest) e doctests.
  2. Vir junto com framework xUnit mais poderoso que o unittest padrão do Python. O py.test tem umas idéias legais. Juntar outras bibliotecas auxiliares, tais como o mocker, também seria legal.
  3. Ter um sistema de discovery automático para testes (ex. nose).
  4. Ter uma interface texto para uso em servidores de testes.
  5. Ter uma interface gráfica para uso do desenvolvedor.
  6. Suportar execução distribuída de testes. Ainda não preciso disso mas estou prevendo que precisarei no futuro.
  7. Integração com algum software de lint (ex. pylint).
  8. Integração com sistemas de teste de cobertura (ex. coverage).
  9. Emitir relatório sobre a qualidade do código (baseado na análise do lint), da cobertura dos testes, do tempo de execução dos testes e, em caso de falha, o traceback do erro.
  10. Permitir a execução do pdb caso algum teste falhe.
  11. Integração com o mecanismo de persistência de objetos (ORM, OODBMS, …) para permitir a criação de savepoints (aka subtransactions) para testes que precisam construir cenários com muitos objetos. Criando esses savepoints um teste poderia fazer um rollback parcial dos objetos criados/alterados pelo teste executado anteriormente. Eu usei essa integração na Objective e garanto que era muito útil além de diminuir o tempo para execução dos testes de forma colossal.

Mockup da Tela
Modelo da interface gráfica dessa aplicação*.

Esse é o sistema dos meus sonhos e acredito que, conforme o desenvolvimento do meu projeto avance, eu acabe com algo muito parecido nas mãos. Mas se alguém quiser começar antes eu prometo que usarei e, caso me sobre tempo, ajudarei no desenvolvimento 🙂

Quem sabe um dia esse carinha trabalhe integrado a um SCM, ao reviewboard e a um sistema de issue tracker… mas chega de viagem, hora de voltar ao trabalho.

* Note que ainda está faltando uma Treeview para selecionar o módulo cujo código fonte será exibido.

Publicado por

Osvaldo Santana

Desenvolvedor Python e Django, Empreendedor, dono de uma motocicleta esportiva, hobbysta de eletrônica, fã de automobilismo e corinthiano