Comment l'unité de test qui ExecutorService engendre nouveau thread pour la tâche?

Comment fonctionne une unité de test d'un nouveau thread a été créée pour un Exécutable tâche lors de l'utilisation d'un ExecutorService?

En gros, j'ai un static pool de threads pour mon application.

public static final ExecutorService executorService = Executors.newCachedThreadPool();

Je voudrais utiliser ce pool de threads pour mes tests d'unité, plutôt que de se moquant de l'un ou l'injection d'un nouveau pool de threads, puisque les différents pools de threads peut modifier radicalement le comportement de mon application (fixe ou mis en cache vs prévue, etc); je veux m'assurer que je l'ai tester le comportement de l'application avec ses moment de l'exécution du pool de threads.

Cache pool de threads semble fonctionner le mieux pour moi. Le problème est que depuis qu'il est statique et que les fils sont mis en cache pendant 60 secondes, seul le premier test sera effectivement générer un nouveau thread dans la piscine, tandis que les tests ultérieurs de la réutilisation de ce thread.

Code de test unitaire:

public void testDoCallExecutesTaskInAnotherThread() {    
    final Client client = this.createClient();
    final ThreadPoolExecutor threadPoolExecutor = (ThreadPoolExecutor) client.getExecutorService(); //gets the static thread pool
    final int initPoolSize = threadPoolExecutor.getPoolSize();
    final Response response = client.doCall();
    Assert.assertEquals(initPoolSize + 1, threadPoolExecutor.getPoolSize());
}

Des conseils sur la façon de le faire fonctionner, ou une autre approche complètement serait appréciée.

Pourquoi avez-vous si le client effectue l'appel dans un thread séparé? Je peux voir soucier de choses comme, "combien de temps cela prend-il?" ou "est-ce le fonctionnement de répondre correctement à une interruption." Mais comme il se trouve, cela semble être une mauvaise application de tests unitaires.
Bonne question. Ce client doit exécuter un appel de service web <b>de manière asynchrone</b> de sorte qu'il ne résiste pas à l'objet qui l'utilise -- un problème de performances dans ma demande. Je ne suis pas d'attente pour une réponse, je veux juste me assurer que la tâche qui fait un appel de service web a vu le jour de manière asynchrone.
C'est ce que je pensais. Donc, ce que vous devriez vraiment le tester pour savoir s'il "[s] jusqu'à l'objet qui l'utilise". C'est, combien de temps faut-il prendre? Je peux mettre en œuvre doCall de telle manière qu'il faut deux jours pour revenir, mais fait tout de même l'exécuteur de créer un autre thread; votre unité de test de passer, même si votre critère est violé.

OriginalL'auteur Ben Simmons | 2009-11-03

  1. 19

    Moquer de la ThreadFactory:

      ThreadFactory mock = new CustomObservableThreadFactory();
  ExecutorService executorService = Executors.newCachedThreadPool(mock);
    1. Injecter le ExecutorService dans la classe sous test comme d'habitude
    2. Mais l'utilisation d'une personnalisé ThreadFactory pour la création de la mise en cache de pool de threads:
      Le ThreadFactory sera appelé à chaque fois qu'un nouveau Thread est d'être appelé.
      Vous pouvez alors tracer ces instanciations que vous le souhaitez, e.g.avec un écouteur ou un comptoir.

    OriginalL'auteur mhaller