Por que Mockito não zomba de methods estáticos?

Eu li alguns tópicos aqui sobre methods estáticos, e acho que entendo os problemas que o mau uso / uso excessivo de methods estáticos pode causar. Mas eu não cheguei ao fundo do porquê é difícil zombar dos methods estáticos.

Eu sei que outros frameworks de zombaria, como o PowerMock, podem fazer isso, mas por que o Mockito não pode?

Eu li este artigo , mas o autor parece ser religiosamente contra a palavra static , talvez seja minha má compreensão.

Uma explicação / link fácil seria ótimo.

    Eu acho que o motivo pode ser que as bibliotecas de objects mock normalmente criam mock criando dinamicamente classs em tempo de execução (usando cglib ). Isso significa que eles implementam uma interface em tempo de execução (é o que a EasyMock faz, se não me engano), ou herdam da turma a simulação (é o que Mockito faz se não me engano). Ambas as abordagens não funcionam para membros estáticos, pois você não pode substituí-las usando inheritance.

    A única maneira de simular estática é modificar o código de byte de uma class em tempo de execução, o que, suponho, é um pouco mais complicado que a inheritance.

    Esse é o meu palpite, por que vale a pena …

    Se você precisar zombar de um método estático, ele será um forte indicador de um design ruim. Normalmente, você zomba da dependência de sua class em teste. Se a sua class em teste se referir a um método estático – como java.util.Math # sin por exemplo – isso significa que a class em teste precisa exatamente dessa implementação (de precisão versus velocidade, por exemplo). Se você quiser abstrair a partir de uma implementação de sinusite concreta, você provavelmente precisará de uma interface (você verá para onde isso vai acontecer)?

    Eu realmente acho que é um cheiro de código se você precisar simular methods estáticos também.

    • Métodos estáticos para acessar funcionalidade comum? -> Use uma instância singleton e injetar isso
    • Código de terceiros? -> Envolva-o em sua própria interface / delegado (e, se necessário, torne-o um singleton também)

    A única vez que isso parece um exagero para mim, são bibliotecas como o Guava, mas você não precisa zombar desse tipo, porque é parte da lógica … (coisas como Iterables.transform (..))
    Dessa forma, o seu próprio código permanece limpo, você pode ridicularizar todas as suas dependencies de forma limpa, e você tem uma camada anti-corrupção contra dependencies externas. Eu vi o PowerMock em prática e todas as classs que precisávamos eram mal projetadas. Além disso, a integração do PowerMock às vezes causou sérios problemas
    (por exemplo, https://code.google.com/p/powermock/issues/detail?id=355 )

    PS: O mesmo vale para methods privados também. Eu não acho que os testes devam saber sobre os detalhes dos methods privados. Se uma aula é tão complexa que tenta ridicularizar methods privados, é provavelmente um sinal para dividir essa class …

    Mockito retorna objects, mas estático significa “nível de class, não nível de object”. Portanto, o mockito fornecerá uma exceção de ponteiro nulo para estática.

    Em alguns casos, os methods estáticos podem ser difíceis de testar, especialmente se precisarem ser ridicularizados, e é por isso que a maioria dos frameworks de simulação não os suportam. Eu achei este blog muito útil para determinar como simular methods e classs estáticos.