Aproveitando o gancho do post anterior sobre manipulação de dependências, decidi dedicar um post apenas sobre este tema, pois acredito ser de grande ajuda para todos desenvolvedores que precisam manter código legado.
Em projetos legados é comum encontrarmos classes Util (aka Helpers) espalhadas por todo o código, fazendo desde coisas simples como formatar datas ou números, até coisas mágicas como cache de objetos, operações com reflection, escrita de logs, etc. Mesmo que tenham sua “utilidade”, são um terror quando falamos de testes! Além de ser um forte indício de um design fraco, as chamadas a seus métodos, geralmente estáticos, geram dependências nas classes que a utilizam.
Este é a estrutura comum (bem simplificada) de uma classe Util com métodos estáticos:
public class MagicUtil {
public static String getConstanteSecreta() {
return "VALOR_SECRETO_AMBIENTE";
}
}
Neste caso, uma boa estratégia para os testes seria encapsular a chamada da classe Util em um método protected, para que seja sobrescrito na classe de teste, assumindo o comportamento desejado. Porém, se a classe Util for largamente referenciada no projeto (o que é comum) seria preciso refatorar todas a classes que a utilizam para escrever um teste completo.
A estratégia proposta é refatorar a classe Util, aplicando o padrão Singleton e transformando os métodos estáticos em métodos de instância, porém mantendo as assinaturas estáticas, que devem referenciar os métodos da instância. Uma vez que a Util pode ser instanciada (mesmo que internamente), é possível manipular seu comportamento através da injeção de um objeto Mock, por exemplo:
public class MagicUtil {
private static MagicUtil instance = new MagicUtil();
protected static MagicUtil getInstance() {
return instance;
}
protected static void setInstance(MagicUtil obj) {
instance = obj;
}
public String getConstanteSecretaInstancia() {
return "VALOR_SECRETO_AMBIENTE";
}
public static String getConstanteSecreta() {
return getInstance().getConstanteSecretaInstancia();
}
}
Assim, a Util continua com o mesmo comportamento e seu contrato foi mantido. Agora, no seu teste, basta escrever o mock (estendendo a classe e sobrescrevendo os métodos) e injetá-lo na instância interna da Util:
public class ClasseTest {
@Test
public void testaMetodoDependenteDeMagicUtil() {
new MagicUtil() {
{
setInstance(this);
}
public String getConstanteSecretaInstancia() {
return "MEU_VALOR_MOCK";
}
};
Assert.assertEquals("MEU_VALOR_MOCK", MagicUtil.getConstanteSecreta());
}
}
Neste caso a classe anônima (que estende a Util) passa sua própria instância (this) para o método protegido setInstance(). Note que a chamada do método (estático) da Util continua igual ao da classe original, sem o refactoring.
Nos projetos que preciso manter, esta estratégia tem sido muito útil para resolver os problemas das “teias” de Utils. Porém é um recurso paliativo e não deve ser utilizado como o “padrão”. O ideal é sempre evitar classes Utils, lembrando que uma classe deve sempre ter comportamentos bem definidos e o nome já deve indicar sua responsabilidade.