Como lidar com classes de utilitários estáticos ao projetar para testabilidade

Esta é definitivamente uma pergunta / resposta opinativa, mas pelo que vale a pena eu pensei em lançar meus dois centavos. Em termos de estilo TDD, o método 2 é definitivamente a abordagem que o segue ao pé da letra. O argumento para o método 2 é que, se você quiser substituir a implementação de uma dessas classes - digamos, uma biblioteca ImageIO equivalente -, você poderá fazê-lo mantendo a confiança nas classes que utilizam esse código.

No entanto, como você mencionou, se você usar muito de métodos estáticos, você acabará escrevendo muito código de wrapper. Isso pode não ser uma coisa ruim a longo prazo. Em termos de sustentabilidade, há certamente argumentos para isso. Pessoalmente eu preferiria essa abordagem.

Dito isto, o PowerMock existe por um motivo. É um problema bastante conhecido que testar quando os métodos estáticos estão envolvidos é seriamente doloroso, daí a criação do PowerMock. Eu acho que você precisa pesar suas opções em termos de quanto trabalho será para envolver todas as suas classes auxiliares versus usando PowerMock. Eu não acho que é desistir de usar o PowerMock - eu sinto que envolver as classes permite mais flexibilidade em um grande projeto. Quanto mais contratos públicos (interfaces) você puder fornecer ao limpador, a separação entre a intenção e a implementação.

Como referência para todos que também estão lidando com esse problema e se depararem com essa questão, descreverei como decidimos resolver o problema:

Basicamente, seguimos o caminho descrito como # 2 (classes de wrapper para utilitários estáticos). Mas nós só os usamos quando é muito complexo para fornecer à concessionária os dados necessários para produzir a saída desejada (ou seja, quando temos que ridicularizar o método).

Isso significa que não precisamos escrever um wrapper para um utilitário simples como o Apache Commons StringEscapeUtils (porque as strings que eles precisam podem ser fornecidas facilmente) e não usamos mocks para métodos estáticos (se achamos que podemos precisa de tempo para escrever uma classe wrapper e, em seguida, zombar de uma instância do wrapper).

Eu testaria essas classes usando o Groovy . O Groovy é simples de adicionar em qualquer projeto Java. Com isso, você pode zombar dos métodos estáticos com bastante facilidade. Veja Mocking Static Methods usando Groovy para um exemplo.

Eu trabalho para uma grande companhia de seguros e nosso código-fonte sobe para 400MB de arquivos java. Temos desenvolvido todo o aplicativo sem pensar em TDD. A partir de janeiro deste ano, começamos com testes junit para cada componente individual.

A melhor solução em nosso departamento era usar objetos Mock em alguns métodos JNI que eram confiáveis para o sistema (escritos em C) e, como tal, você não poderia estimar exatamente os resultados todas as vezes em todos os sistemas operacionais. Não tínhamos outra opção senão usar classes ridicularizadas e implementações específicas de métodos JNI especificamente para o propósito de testar cada módulo individual do aplicativo para cada SO que suportamos.

Mas foi muito rápido e tem funcionado muito bem até agora. Eu recomendo - link

Os objetos interagem uns com os outros para atingir um objetivo, quando você tem um objeto difícil de testar devido ao ambiente (um ponto de extremidade do serviço web, camada dao acessando o banco de dados, controladores lidando com parâmetros de solicitação http) ou deseja testar seu objeto isolamento, então você zomba desses objetos.

a necessidade de zombar de métodos estáticos é um mau cheiro, você tem que projetar sua aplicação mais Orientada a Objetos, e métodos estáticos de teste unitário não agregam muito valor ao projeto, a classe wrapper é uma boa abordagem dependendo da situação , mas tente testar os objetos que usam os métodos estáticos.

Às vezes, uso a opção 4

4. Use o padrão de estratégia. Crie uma classe de utilitário com métodos estáticos que delegam a implementação a uma instância de interface conectável. Codifique um inicializador estático que se conecte em uma implementação concreta. Conecte uma implementação simulada para teste.

Algo parecido com isto.

public class DateUtil {
    public interface ITimestampGenerator {
        long getUtcNow();
    }

    class ConcreteTimestampGenerator implements ITimestampGenerator {
        public long getUtcNow() { return System.currentTimeMillis(); }
    }

    private static ITimestampGenerator timestampGenerator;

    static {
        timestampGenerator = new ConcreteTimeStampGenerator;
    }

    public static DateTime utcNow() {
        return new DateTime(timestampGenerator.getUtcNow(), DateTimeZone.UTC);
    }

    public static void setTimestampGenerator(ITimestampGenerator t) {...}

    // plus other util routines, which may or may not use the timestamp generator 
}

O que eu gosto nessa abordagem é que ela mantém os métodos de utilitários estáticos, o que parece certo para mim quando estou tentando usar a classe em todo o código.

Math.sum(17, 29, 42);
// vs
new Math().sum(17, 29, 42);