Pré requisitos

Bom,

Com o objetivo traçado, agora vem os requisitos mínimos para uma versão inicial. Partiremos do pré suposto, que algumas das funcionalidade disponibilizadas pelo jUnit deverão ser contempladas, para que os primeiros casos de teste sejam cobertos.
Acredito que futuramente, seja até possível inovar, criar novos atalhos para os testes, mas por enquanto iremos focar no básico, ou seja, nem tudo que o jUnit oferece estará coberto, então segue uma singela lista do que será possível e obrigatório ter em uma anotação de teste na versão inicial:

• Deverá ter um nome
• Caso o teste tenha parâmetros, os passados ao teste deverão coincidir
• Deverá ter um valor esperado, caso o método não seja void
• Deverá testar exceções dos métodos, quando aplicável
• Deverá aceitar todos tipos de asserts do jUnit (true, false, equals, notEquals, maior, menor, etc...)
• Deverá permitir referenciar mocks, que serão separadamente criados
• Deverá permitir criar um ou mais testes por método

Apesar de ser uma lista não muito ambiciosa, já oferece muitos obstáculos que deverão ser vencidos...

Primeiras propostas

Vamos lá, como que vai funcionar?

Começou o BrainStorm...

• Vai ter console, linha de comando
• Vai ter plugin no eclipse
• Vai ser uma extensão do jUnit
• Vai ser um plugin do maven, que vai rodar antes da fase de compilação
• Vai ter que conhecer a fundo a VM, pra não ir lixo pro byte code
• Vai ter que suportar mock, exception, data provider, todos tipos de assert
• Vai ter que ter uma sintaxe lógica e intuitiva para a anotação, algo que lembre um selector ou até mesmo um comando sql

Enfim, várias discussões brotaram até o mais organizado do grupo dar a sugestão que iria dar o norte pro projeto.

"Quem sabe a gente não começa descrevendo o objetivo da API, assim fica mais fácil de alinhar os pensamentos e definir como irá funcionar"

Perfeito! Começar pelo começo.

Objetivo 

Criar uma API de teste de unidade, que gere automaticamente cenários de teste através de anotação java nos métodos das classes de negócio sem a necessidade de criar classes de teste.

Ainda está muito vago e subjetivo, mas acredito que ao decorrer do tempo e das experiências ele se torne mais "objetivo".

StartUp

Há dois dias se consolidou uma ideia que estava a um bom tempo engavetada. A ideia é simples, mas pra concretizá-la há um longo caminho. Lá vai ela...

Criar testes de unidade a partir de um conjunto de anotações realizadas diretamente na classe de negócio

Lancei a ideia para dois colegas de trabalho que com certeza são as pessoas que poderão tornar isso possível de forma mais rápido e elegante, e então decidimos que iríamos criar um projeto projeto Open Source pra isso, mas a versão 1.0 já seria funcional e nós que iríamos criar.

Em um primeiro momento de reflexão, alguns pontos positivos foram levantados:

• Padronização e organização do código de teste
• Centralização da regras de negócio e casos de teste
• Escrita de teste (TDD) já direto na classe de negócio
• Economia de tempo de elaboração sintática dos teste
• Entre outras...

Assim como pontos negativos:

• Excesso de informação na classe de negócio
• Dificuldade de abstração na elaboração de código (TDD também)
• Entre outras.

Ainda não temos certeza sobre a visão desses prós e contras, e acredito que serão defendidos de acordo com o público, mas o importante é que algum tempo será dedicado a essa ideia, para se ter certeza se ela é viável ou não.

Tomara que sim...