O nome já diz: que é para testar uma unidade.
Qual unidade? A menor possível devido a coesão.
O que é menor: Classe e seus métodos públicos.
Se uma classe tem relacionamentos de dependência com outras classes, o teste dessa unidade vai ficar comprometido em tempo e isolamento.
Por que tempo? Porque no tempo que se testa essa unidade, talvez as dependências dela não estejam testadas.
Por que isolamento? Porque as dependências podem não estar 100% testadas e não se poderia dizer com certeza qualquer erro nessa unidade é dela própria ou de alguma dependência.
Como resolver o problema do tempo em que se testa uma unidade?
Deve-se criar um teste para toda unidade a qualquer tempo.
Usa-se objetos mocks para substituirem instâncias de classes que são dependência de unidade de teste.
Não seria uma boa solução desenvolver uma api que precise trabalhar com requisições externas sem mocks.
Com uns 20 testes o build demoraria minutos para rodar e em dado momento pode tornar-se inviável acrescentar mais testes.
Mock nos força a programarmos usando interfaces, e isso muitas vezes não é saudável.
Assumimos que vai existir mais de um tipo do objeto, o que ainda na elaboração não temos como garantir.
Ou seja, podemos cair no erro de fazer design para coisas que podem não existir e esse é um dos caminhos que levam pro inferno.
Mocks (não apenas o mockito) mandam pro limbo todas aquelas idéias bonitas sobre baixo acomplamento.
Você está escrevendo um teste completamente acoplado à sua implementação atual do objeto.
Refatore ela e os seus testes com mock podem quebrar.
Pior ainda, eles podem continuar passando mas não estar testando mais nada.