http://www.codeatest.com/mockito-isolamento-testes-unidade/
Uma das características fundamentais de um bom teste unitário é ser isolado. Para que ele execute rápido, fornecendo feedback ao desenvolvedor, ele deve ser isolado. Quando digo isolado é que ele deve ser isolado de dependências externas: acesso à rede, ao sistema de arquivos, a banco de dados etc. É aí que os mocks podem nos ajudar e que o Mockito entra em ação.
Imagine que você precisa testar um código que faz acesso à camada de persistência por meio de um DAO/Repository. Para esse código funcionar, em produção, é necessário que algum mecanismo de persistência (um banco de dados relacional, por exemplo) esteja disponível. Para o código de testes de unidade isso é impraticável: ele vai ficar lento, mais complexo, vai perder o isolamento.
A solução para o caso anterior é simular o acesso à camada de persistência. Daí o uso de mocks. De maneira geral, para facilitar o entendimento, mocks são objetos criados para simular, de forma controlada, determinados comportamentos de objetos reais. Por forma controlada entenda: como bem quisermos ou desejarmos.
O Mockito, como veremos a seguir, nos auxilia na tarefa de criação de mocks. Vamos, então, conhecer um pouco mais dele.
Esse caso é bem simples: dada uma lista de tarefas ele verifica se todas as tarefas tiveram o responsável atribuído. A linha em destaque (replicada abaixo) mostra o uso do Mockito nesse teste para simular o retorno da lista de tarefas.
when(tarefasService.todas(sprint)).thenReturn(listaTarefas);
O que fizemos foi “ensinar” ao Mockito quando (when()) o método todas()do nosso mock tarefasService for chamado, que seja retornada (thenReturn()) a nossa lista de tarefas criada previamente. Com isso, ao executar o código em teste, em vez de o método todas() original ser chamado ele chamará o método em nosso mock.
TDD em Android -
ListaLeilaoAdapter adapter = Mockito.spy(new ListLeilaoAdapter(new Context(){ ... }));
Mockito.doNothing().when(adapter).notifyDataSetChanged(); //metodo estatico
//quando chamar o metodo notifyDataSetChanged nao faca nada.
porem o mockito nao consegue alterar o que for final ou static.
Para o cenario acima o metodo notifyDataSetChanged() foi colocado em um metodo public e assim o novo metodo que deve ser chamado pelo Mockito.
//verifica se algum metodo foi chamado
Mockito.verify(adapter).atualizaLista();