Paralelamente ao meu trampo Java EE, estou desenvolvendo um sisteminha para controle financeiro em Rails. E tudo o que vejo de errado, ou que poderia ser melhor aqui na empresa, estou tentando levar no meu projeto. E uma das coisas é o TDD. Evidentemente testes unitários deveriam ser prioridade em qualquer sistema de informação, mas sabemos que na realidade, as vezes a diretoria pressiona, e você tem que correr com o codigo e deve deixar algo de lado, para encaixar no prazo. Geralmente esse “algo” que fica de lado, é o teste. Com rails/ruby, é possível explorar mais ainda o TDD. Pelo fato de ser uma linguagem dinâmica, é possivel você criar o teste antes do código. Parece estranho né ? Mas isso te força a sempre codificar pensando no teste e sempre testar pensando no código. E acredite, isto faz uma enorme diferença.

Temos alguns sistemas legados aqui na empresa, que não tiveram esta preocupação com o teste. Devido, provavelmente ao que relatei no parágrafo anterior. E agora estamos com muito receio de refatorar o código, pois não temos a segurança que uma boa suite de teste nos daria. Ai você me diz: “Simples! Faça a tal suite de testes, e depois refatora!”. Entretanto, o sistema não foi feito pensando em testes, não foi concebido para ser unitariamente testado. Com isso temos o codigo de negocio completamente vinculado ao acesso ao banco, o que torna praticamente impossível a utilização de uma camada de mocks. Ou seja, estamos em maus lençóis.