Test de l'unité Android avec Retrofit2 et Mockito ou Robolectric

Puis-je tester la réponse réelle de retrofit2beta4? Ai-je besoin de Mockito ou Robolectic?

Je n'ai pas d'activités dans mon projet, ce sera une bibliothèque et je dois tester si le serveur répond correctement. Maintenant, j'ai tel code et coincé …

  • Traduction des événements tactiques de Javascript vers jQuery
  • Comment mettre l'authentification des utilisateurs dans une application mobile
  • Les itinéraires mobiles de l'emplacement actuel
  • L'application Google Play Top Charts n'est plus classée après avoir changé de titre?
  • Unit Test of Retrofit 2 api appel avec Mockito
  • Ajout d'un marqueur multiple sur google map dans Android
  • @Mock ApiManager apiManager; @Captor private ArgumentCaptor<ApiCallback<Void>> cb; @Before public void setUp() throws Exception { apiManager = ApiManager.getInstance(); MockitoAnnotations.initMocks(this); } @Test public void test_login() { Mockito.verify(apiManager) .loginUser(Mockito.eq(login), Mockito.eq(pass), cb.capture()); // cb.getValue(); // assertEquals(cb.getValue().isError(), false); } 

    Je peux faire une fausse réponse, mais j'ai besoin de tester réel. Est-ce que c'est un succès? Est-ce que le corps est correct? Pouvez-vous m'aider avec le code?

  • Convention de dénomination id d'Android: minuscule avec le trait de soulignement contre le boîtier de chameau
  • Javascript max viewport height after orientation changez Android et iOS
  • Faire en sorte que l'appareil Android de Samsung apparaisse comme un iBeacon
  • JQuery - Autoriser le clavier Autoshow sur mobile
  • Comment créer une UI comme le nouveau marché ou Google plus?
  • Comment détecter automatiquement le besoin d'iScroll?
  • 3 Solutions collect form web for “Test de l'unité Android avec Retrofit2 et Mockito ou Robolectric”

    Il n'est généralement pas une bonne idée de tester les demandes réelles du serveur. Voir cette publication sur le blog pour une discussion intéressante sur le sujet. Selon l'auteur, l'utilisation de votre serveur réel est un problème car:

    • Une autre pièce mobile qui peut échouer par intermittence
    • Nécessite une expertise en dehors du domaine Android pour déployer le serveur et le maintenir à jour
    • Difficile de déclencher des cas d'erreur / bord
    • Exécution lente du test (toujours en cours d'appel HTTP)

    Vous pouvez éviter tous les problèmes ci-dessus en utilisant un serveur simulé tel que le MockWebServer d' OkHttp pour simuler des résultats de réponses réelles. Par exemple:

     @Test public void test() throws IOException { MockWebServer mockWebServer = new MockWebServer(); Retrofit retrofit = new Retrofit.Builder() .baseUrl(mockWebServer.url("").toString()) //TODO Add your Retrofit parameters here .build(); //Set a response for retrofit to handle. You can copy a sample //response from your server to simulate a correct result or an error. //MockResponse can also be customized with different parameters //to match your test needs mockWebServer.enqueue(new MockResponse().setBody("your json body")); YourRetrofitService service = retrofit.create(YourRetrofitService.class); //With your service created you can now call its method that should //consume the MockResponse above. You can then use the desired //assertion to check if the result is as expected. For example: Call<YourObject> call = service.getYourObject(); assertTrue(call.execute() != null); //Finish web server mockWebServer.shutdown(); } 

    Si vous devez simuler des retards de réseau, vous pouvez personnaliser votre réponse comme suit:

     MockResponse response = new MockResponse() .addHeader("Content-Type", "application/json; charset=utf-8") .addHeader("Cache-Control", "no-cache") .setBody("{}"); response.throttleBody(1024, 1, TimeUnit.SECONDS); 

    Alternativement, vous pouvez utiliser MockRetrofit et NetworkBehavior pour simuler les réponses de l'API. Voir ici un exemple de l'utilisation.

    Enfin, si vous voulez simplement tester votre service de réaménagement, le plus simple serait de créer une version simulée qui émet des résultats simulés pour vos tests. Par exemple, si vous disposez de l'interface de service GitHub suivante:

     public interface GitHub { @GET("/repos/{owner}/{repo}/contributors") Call<List<Contributor>> contributors( @Path("owner") String owner, @Path("repo") String repo); } 

    Vous pouvez ensuite créer le MockGitHub suivant pour vos tests:

     public class MockGitHub implements GitHub { private final BehaviorDelegate<GitHub> delegate; private final Map<String, Map<String, List<Contributor>>> ownerRepoContributors; public MockGitHub(BehaviorDelegate<GitHub> delegate) { this.delegate = delegate; ownerRepoContributors = new LinkedHashMap<>(); // Seed some mock data. addContributor("square", "retrofit", "John Doe", 12); addContributor("square", "retrofit", "Bob Smith", 2); addContributor("square", "retrofit", "Big Bird", 40); addContributor("square", "picasso", "Proposition Joe", 39); addContributor("square", "picasso", "Keiser Soze", 152); } @Override public Call<List<Contributor>> contributors(String owner, String repo) { List<Contributor> response = Collections.emptyList(); Map<String, List<Contributor>> repoContributors = ownerRepoContributors.get(owner); if (repoContributors != null) { List<Contributor> contributors = repoContributors.get(repo); if (contributors != null) { response = contributors; } } return delegate.returningResponse(response).contributors(owner, repo); } } 

    Vous pouvez ensuite utiliser le MockGitHub sur vos tests pour simuler les types de réponses que vous recherchez. Pour l'exemple complet, voir les implémentations de SimpleService et SimpleMockService pour cet exemple de rétrofit .

    Après avoir dit tout cela, si vous devez absolument vous connecter au serveur actuel, vous pouvez configurer Retrofit pour fonctionner de manière synchrone avec un ImmediateExecutor personnalisé:

     public class ImmediateExecutor implements Executor { @Override public void execute(Runnable command) { command.run(); } } 

    Ensuite, appliquez-le à OkHttpClient vous utilisez lors de la construction de l'adaptation:

     OkHttpClient client = OkHttpClient.Builder() .dispatcher(new Dispatcher(new ImmediateExecutor())) .build(); Retrofit retrofit = new Retrofit.Builder() .client(client) //Your params .build(); 

    La réponse est trop simple de ce que je m'attendais:

    L'utilisation de CountDownLatch fait attendre votre test jusqu'à ce que vous appeliez countDown ()

     public class SimpleRetrofitTest { private static final String login = "your@login"; private static final String pass = "pass"; private final CountDownLatch latch = new CountDownLatch(1); private ApiManager apiManager; private OAuthToken oAuthToken; @Before public void beforeTest() { apiManager = ApiManager.getInstance(); } @Test public void test_login() throws InterruptedException { Assert.assertNotNull(apiManager); apiManager.loginUser(login, pass, new ApiCallback<OAuthToken>() { @Override public void onSuccess(OAuthToken token) { oAuthToken = token; latch.countDown(); } @Override public void onFailure(@ResultCode.Code int errorCode, String errorMessage) { latch.countDown(); } }); latch.await(); Assert.assertNotNull(oAuthToken); } @After public void afterTest() { oAuthToken = null; }} 

    Sauf si vous testez l'API du serveur QA, c'est une mauvaise idée pour plusieurs raisons.

    • Tout d'abord, vous gérez votre base de données de production avec des données fausses / fausses
    • Utilisation des ressources du serveur, lorsqu'elles peuvent mieux utiliser pour répondre à une demande valide

    La meilleure façon d'utiliser Mockito, ou Mock your responses

    En outre, si vous devez tester votre API de production, testez-le une fois et ajoutez l'annotation @Ignore. De cette façon, ils ne sont pas exécutés tout le temps et ne spamme pas votre serveur avec des données fausses et vous pouvez l'utiliser chaque fois que vous sentez que l'api ne se comporte pas correctement.

    coAndroid est un fan Android de Google, tout sur les téléphones Android, Android Wear, Android Dev et Android Games Apps.