Testes dirigem o design

Pois é, esses dias tive uma discussão na xprio sobre um teste que estava bem complicado, isso contraria várias idéias de que os testes não devem ser tão complicados de implementar, o que é verdade, eles não devem ser complicados, bem, o caso era o seguinte:

Estava testando um método:

0: public void enviaEmail()
1: {
2:  // faz um monte de coisa
3:  Mail mail = new Mail();
4:  mail.send("Titulo", "Corpo", "email@email.com.br");
5:
6:  // faz outro monte de coisa
7: }

Dentro deste método, crio a instância de outra classe(Mail) e invoco o método(send) desta. Aí esta o problema, este método(send) envia emails, e isso é algo que não preciso que meu teste faça.

O Danilo Sato levantou esta bola(o teste dirige o design), e me fez algumas perguntas:

* Que tal passar o e-mail pronto como parâmetro?
* Vale a pena ter o e-mail como atributo dessa classe?
* Qual a responsabilidade dessa classe que está testando? enviar o
e-mail ou criar o email?

Essas perguntas podem ser generalizadas e usadas em situações onde o teste se torne mais complicado.

Como se trata de uma situação onde o código já existe e funciona, fazer uma refatoração é o mais indicado a fazer, nada de grandes manobras, apenas desacoplar algumas funcionalidades ou a criação do objeto, como me indicou o Celestino, com um getInstance por exemplo.

De qualquer forma, fica a lição de que o teste feito quando usamos TDD é normalmente, pra não dizer: sempre, mais simples.