Introdução

Hoje eu gostaria de compartilhar com vocês uma biblioteca que conheci recentemente, ela se chama mock interceptor. Todos nós já passamos por essa situação: ficar esperando eternamente uma API que nunca fica pronta, o que só atrasa o desenvolvimento da nossa aplicação. Sabemos que temos várias alternativas para esse tipo de situação, como mockar o retorno dentro da classe de repository, trazer a tela já preenchida com os dados que desejamos, entre outras.

Acredito que o maior problema nesse tipo de caso é quando queremos testar mais de um retorno possível vindo da API, por exemplo, queremos validar o que acontece quando a api retorna o esperado, ou o que acontece quando retorna ela retorna um erro, ou qualquer outro STATUS_CODE possível. Alterar esses casos de uso no app normalmente também exigem que um rebuild seja feito, e dependendo do tamanho do App isso pode ser demorado.

Tendo isso em mente trago a lib do mock-interceptor.

Como o mock-interceoptor funciona?

Como o próprio nome já diz, a lib funciona como um interceptor para OKHttp. Mockando respostas como se elas viessem diretamente do backend. A lib procura por arquivos na pasta de resources assets usando seu conteúdo como BODY do response.

Isso nos trás uma série de benefícios tais como:

• Desenvolvimento Offline
• Infinitos cenários para testar o App
• Mais controle sobre casos de uso específicos
• E o melhor, alternar entre esses cenários sem rebuild.

Configuração

Para começar a utilizar o mock-interceptor basta apenas adicionar a lib ao projeto

def mock_version = 1.0.0

implementation ‘com.github.gustafah:mock-interceptor:$mock_version’

https://github.com/gustafah/mock-interceptor

Vamos assumir que a lib do Retrofit  também está sendo usada no projeto.

Agora vamos adicionar o interceptor a implementação do retrofit.

Para isso é só adicionar o código abaixo a implementação do retrofit

É importante adicionar o interceptor Logging de Level BODY, para poder visualizar os logs que o interceptor do mock vai gerar.

Depois de adicionado o interceptor podemos executar o App. A primeira request que for executada vai falhar, retornando um status 502 com um body.

Vai retornar algo assim

Esse comportamento é descrito no README da lib, e acontece pois ainda não criamos o mock e o interceptor não sabe qual arquivo retornar. No body do response tem uma sugestão de nome do arquivo. O nome do arquivo é criado usando a URL da request, o endpoint e o tipo dela e/ou parâmetro. Usando o .suffix(“.json”) , .separator(“_”) definidos no interceptor.

v3_launches_967_GET.json

Para o primeiro endpoint executado no app a lib sugere o nome acima.

Como criar arquivos de mock?

Como mencionado antes, os arquivos de mock precisam ficar dentro da pasta assets e até agora a lib só aceita arquivos .json

Agora vamos ver a estrutura básica do arquivo de mock, ela é usada para representar o dialog exibido na tela e possui os seguintes parâmetros.

• reference: É uma string que define o nome do mock e é apresentado como titulo do dialog
• default: É um inteiro usado para definir uma resposta padrão para ser mostrada toda vez
  • -2: Usado para respostas aleatórias (O dialog não será mostrado)
  • -1: Nenhum resposta padrão definida (O dialog vai ser mostrado a não ser que tenha apenas uma opção)
  • 0..N: Para selecionar uma posição dentro do array saved_data (O dialog não será mostrado)
• saved_data: O array que contém cada uma das opções que podem ser retornadas pelo backend

A estrutura para cada uma das opções de mock fica da seguinte maneira:

• description: Uma string que define um titulo para essa opção
• code: Representa o status code da request retornada pela API
• O conteúdo que será o body de cada opção pode ser representado de diferentes maneiras
  • data_path: Uma string informando que a resposta para essa opção está dentro de um outro arquivo que também fica dentro da passta assets (isso melhora a organização e tamanho do arquivo)
  • data_array: suporta um jsonarrray indicando que esse response será um array
  • data: Um objeto json indicando que o response será esse objeto.
  • is_unit: Um boleano para indicar quando o response não possui body

Agora que vimos cada uma das opções, podemos montar nosso primeiro arquivo de mock. Vamos começar criando o arquivo conforme o nome sugerido. Para isso vamos na pasta assets e adicionamos um novo arquivo. Caso ela não exista, crie uma.

O nome do arquivo não precisa ser o sugerido pela lib, pode ser qualquer um. Ao usarmos o sugerido não se faz necessário o uso de uma anotação em cima da função que define a request.

No caso de usar um nome diferente do sugerido precisa ser feito o seguinte.

Como vai ficar o arquivo json de mock:

No caso de o objeto do mock ter apenas um retorno não importa a configuração que vem no valor default. O dialog não será apresentado, como podemos notar.

Vamos adicionar mais uma opção para visualizar o dialog de seleção. Para a segunda opção vamos adicionar o data_path especificando o caminho/nome do arquivo.

abaixo o arquivo one_launch_response_67.json

Depois de executarmos podemos ver que um dialog com as opções cadastradas é apresentado.

Podemos adicionar mais 2 opções. Uma que trás um outro lançamento, e outra que trás o  erro e status_code.

Conclusão

Infelizmente precisamos criar mocks para todas as request, ou o App irá quebrar ao fazer essa request. Apesar disso é uma lib muito interessante, que tem muito potencial para auxiliar durante a fase de desenvolvimento do App.