enfim é um projeto interessante, mesmo com a abordagem test-after, mas acho que se este pudesse ser integrado a uma IDE com possibilidades de integração entre alguns frameworks como hibernate, spring, etc., seria muito interessante.
eu acho mais interessante ainda você mudar a abordagem do projeto para test-first, dentro da IDE do projeto que não faça o desenvolvedor sair da tela onde tem o código-fonte, por isso abordagem por plugins seria mais eficaz.
a abordagem test-first torna-se ainda mais interessante para linguagens interpretadas como php, python, ruby, etc, então seu projeto poderia abordar outras linguagens em um futuro mesmo que distante, de forma que pudesse guiar desenvolvedores de outras linguagens ou plataformas, afim de possibilitar adição de outras técnicas como pairwise, análise de domínio, entre outras avançadas por inferência seriam, e muito interessantes.
um aspecto a se preocupar com a abordagem test-first será no tempo de refactoring, pois o refactoring irá caracterizar que o seu design precisa melhorar, e isto significa que você se enganou quanto ao seu design inicial, necessitando modificar, tendo consequentemente mais tempo para ajustar ao design ideal.
com a prática, nós adquirimos maturidade e perdemos medo de escrever código, guiando o desenvolvedor a obter sempre que possível, em momento inicial de confrontação de um dado problema, ter um design mais ideal que consiga ter, a ser resolvido, dado contexto à soluções de seu problema.
o tempo gasto de refactoring pode ser adjetivado como custo adicional em seu projeto em caso do aparente design necessitar ser refatorado.
ora, para guiar o desenvolvedor a melhor eficiência em 1º caso de código implementado, sem perigo de ir consultar no google, onde o termo “eficiência” é mais adequado, pois com o tempo você vai adquirir eficacidade, mesmo em baby steps, tendo consequente bons designs a primeira vista, ao invés de sair sempre refatorando.
este é um dos calos que alguns dizem que o TDD possui. no refactoring! mas aí onde está o equívoco, afinal, se o seu design necessitou de muito refactoring a culpa é toda sua, ou houve uma mudança muito estravagante que caracteriza ingenuidade e falsa impressões iniciais(não sabe o que quer) dos responsáveis pelo projeto.
voltando ao assunto.
um dos maiores problemas em testes são bugs recorrentes, e estes testes, quando implementados, ajudam a evitar parte deste tipo de problema. mas existe um outro problema quanto a testes funcionais, pois estes ainda continuarão, por muito tempo, a existir.
isto deve-se ao fato onde revisões humanas são fundamentais afim de garantir que coisas bobas não identificadas pela máquina ou release quebrado ou falha em configuração não prevista.
afinal,
sabe o que é isto. A M A D O R I S M O, e isto é bastante praticado por “empresas de 3 letrinhas”, como alguns citados aqui pelo guj. e haja muita lábia do gerente com cliente para contornar e evitar cancelamento de projeto. depois de contornado tome chicote para cima da equipe!
ora pode até, ser os três, mas geralmente existe um problema cultural interno que precisa ser resolvido, onde a comunicação, acaba sendo o primeiro da lista.
revisão por parte de uma pessoa humana em ajuste fino, muitas vezes a máquina não é possível identificar, além do que tem-se muito trabalho atualmente para implementar e manter, exigindo-se pouco mais de tempo que, hoje, traz consequências inevitáveis se não tratadas adequadamente afim de evitar que o projeto vá para o buraco.
outro aspectos em testes que icomodam, principalmente líderes e arquitetos de projeto, são testes que tratam requisitos não-funcionais, onde um termo também é abordado para este propósito como “arquiteturas testáveis”.
testes por arquiteturas testáveis trata-se de um aspecto, onde não adianta automatizar com geração de código. praticamente é melhor tentar se beneficiar através do reuso, entre técnicas de padrões de projeto, que só a maturidade envolvida em projetos irá acrescentar motivação em implementá-los.
a disciplina de testes de software não garante 100% de 0 bugs, mas sim uma minimização destes guiados por práticas e técnicas de engenharia que no meu ponto de vista, a maior parte dos esforços deve se concentrar durante o início de desenvolvimento do projeto, e não após.
você poderia expandir até um pouco mais a idéia e abrir o código-fonte no sourceforge, google code, entre outros repositórios, afim de expor melhor sua abordagem para quem tiver interesse e quiser colaborar implementando.
um outro aspecto que você terá que se preocupar será com a manutenção de código gerado, pois a regra de negócios pode mudar, bem como a granuralidade que está sendo tratado, pois a própria palavra teste por alguns é infelizmente considerada um preconceito por escrever tanto código, daí você poderia minimizar este mal hábitos que alguns programadores tem sobre abordagem de testes.
