Facilitando a manutenção dos testes ao diminuir o acoplamento com o código

 public void deveCompararOValorDaAcaoDeDuasEmpresasDiferentes() { // usando um HttpClient simples String uri = "http://servico\_falso\_da\_bovespa\_para\_testes"; HttpClient client = new HttpClient(uri);
BuscadorDePrecos buscador = new BuscadorDePrecosNaBovespa(client);
Comparador compara = new Comparador(buscador); double diferenca = compara.acoesDa("petrobras", "vale");
assertEquals(1.0, diferenca, 0.001); } 

O teste acima verifica se a classe Comparador calcula a diferença entre duas ações. Para isso, ela usa a classe BuscadorDePrecosNaBovespa que, por sua vez, acessa um cliente qualquer de Http (aqui ilustrado como HttpClient) para fazer as requisições.

Esse teste entrega feedback sobre a corretude do programa; batendo contra um servidor parecido com o da Bovespa, recebendo os valores e executando as comparações devidas. Se o programador deseja alterar a implementação do BuscadorDePrecosNaBovespa, removendo o HttpClient para fazer uso de uma outra ferramenta, como o Restfulie, além de quebrar os testes da classe BuscadorDePrecosNaBovespa (que já era esperado), ainda quebrariam os do Comparador. Uma mudança simples, que deveria acarretar em consequências apenas nos testes específicos dessa classe, afeta diferentes classes e testes desse sistema; aumentando o custo de manutenção da bateria de testes, um tradeoff que pode ou não fazer sentido em seu projeto.

Perceba que a classe Comparador não está interessada em como a classe BuscadorDePrecosNaBovespa faz seu trabalho; ela apenas espera que alguém busque esse valor. Se a classe Comparador fosse testada isoladamente, tudo que ela precisaria é receber "alguém" que retorne o valor de uma determinada ação. Ou seja:

A classe Comparador, testada isoladamente, ainda depende de um BuscadorDePrecos, um objeto que saiba como buscar o preço de ações. Mas agora o teste passa para ela um dublê, uma classe que finge ser a outra. O teste desconhece a existência de uma implementação concreta dessa interface.

A classe BuscadorDePrecosNaBovespa (que implementa essa interface) pode ser modificada, sem propagar o custo de manutenção para além da sua própria classe de testes.

Programar para interfaces não só diminui o acoplamento entre as classes de produção, mas também entre seu código de teste e de produção. Devemos buscar sempre o baixo acoplamento, para diminuir os custos de manutenção, não importando onde ele esteja presente.

Testes de integração são fundamentais para validar a corretude do sistema, mas podem apresentar uma barreira para sua evolução. Os desenvolvedores devem pesar a abordagem de testes para garantir o máximo de qualidade interna e externa, mantendo um custo aceitável para o desenvolvimento e evolução a longo prazo.