Comment utiliser JUnit pour tester le processus asynchrones

À mon humble avis c'est une mauvaise pratique d'avoir des tests unitaires de créer ou d'attendre sur les threads, etc. Vous souhaitez ces tests à exécuter, dans des fractions de secondes. C'est pourquoi je voudrais proposer un 2-étapes de l'approche de test async processus.

1. Test que votre async processus est soumis correctement. Vous pouvez vous moquer de l'objet qui accepte vos demandes asynchrones et assurez-vous que le travail a soumis propriétés correctes, etc.
2. Test que votre async rappels sont en train de faire les bonnes choses. Ici, vous pouvez vous moquer de la soumis à l'origine de l'emploi et supposons qu'elle est correctement initialisé et vérifiez que vos rappels sont corrects.

Vous pouvez essayer d'utiliser le Awaitility de la bibliothèque. Il est facile de tester les systèmes dont vous parlez.

Démarrer le processus et d'attendre le résultat à l'aide d'un Avenir.

Il n'y a rien d'intrinsèquement mauvais avec des tests fileté/async code, en particulier si le filetage est le point du code testé. L'approche générale de tester ce genre de choses est à:

• Bloc de l'essai principal fil
• La Capture a échoué affirmations des autres threads
• Débloquer le principal test thread
• Relever les défaillances

Mais c'est beaucoup de passe-partout pour un test. Mieux/approche la plus simple consiste à n'utiliser que ConcurrentUnit:

  final Waiter waiter = new Waiter();

  new Thread(() -> {
    doSomeWork();
    waiter.assertTrue(true);
    waiter.resume();
  }).start();

  //Wait for resume() to be called
  waiter.await(1000);

L'avantage de cette sur la CountdownLatch approche est qu'il est moins verbeux depuis affirmation défaillances qui se produisent dans n'importe quel thread sont correctement signalés pour le thread principal, sens le test échoue quand il le faut. Un article qui compare les CountdownLatch approche ConcurrentUnit est ici.

J'ai aussi écrit un post de blog sur le sujet pour ceux qui veulent en savoir un peu plus en détail.

Il vaut la peine de mentionner qu'il est très utile chapitre Testing Concurrent Programs dans La simultanéité dans la Pratique qui décrit certains tests unitaires approches et donne des solutions aux problèmes.

D'éviter les essais avec des fils parallèles à chaque fois que vous le pouvez (qui est la plupart du temps). Cela ne fera que rendre votre tests feuilletée (parfois passer, parfois non).

Seulement lorsque vous en avez besoin à appeler un autre bibliothèque ou le système, vous pourriez avoir à attendre sur les autres threads, dans ce cas, utilisez toujours la Awaitility de la bibliothèque au lieu de Thread.sleep().

Jamais appel get() ou join() dans vos tests, d'autre votre de tests peut toujours courir sur votre serveur CI dans le cas où l'avenir ne se termine jamais. Toujours affirmer isDone() d'abord dans vos tests avant d'appeler get(). Pour CompletionStage, c'est-à .toCompletableFuture().isDone().

Lorsque vous testez une méthode non bloquante comme ceci:

public static CompletionStage<String> createGreeting(CompletableFuture<String> future) {
    return future.thenApply(result -> "Hello " + result);
}

alors vous ne devriez pas simplement tester le résultat en passant un achevé d'Avenir dans le test, vous devez également vous assurer que votre méthode doSomething() ne sont pas bloquées par l'appel de join() ou get(). Ceci est important, en particulier si vous utilisez un non-bloquant cadre.

Pour ce faire, effectuez un test avec un non-achèvement de l'avenir que vous avez terminé manuellement:

@Test
public void testDoSomething() throws Exception {
    CompletableFuture<String> innerFuture = new CompletableFuture<>();
    CompletableFuture<String> futureResult = createGreeting(innerFuture).toCompletableFuture();
    assertFalse(futureResult.isDone());

    //this triggers the future to complete
    innerFuture.complete("world");
    assertTrue(futureResult.isDone());

    //futher asserts about fooResult here
    assertEquals(futureResult.get(), "Hello world");
}

De cette façon, si vous ajoutez future.join() de doSomething(), le test échouera.

Si votre Service utilise un ExecutorService comme dans thenApplyAsync(..., executorService), puis dans vos tests injecter un single-threaded ExecutorService, comme celui de goyave:

ExecutorService executorService = Executors.newSingleThreadExecutor();

Si votre code utilise la forkJoinPool comme thenApplyAsync(...), réécrire le code pour utiliser un ExecutorService (il y a beaucoup de bonnes raisons), ou de l'utilisation Awaitility.

Pour raccourcir l'exemple, j'ai fait BarService l'argument d'une méthode de mise en œuvre comme un Java8 lambda dans le test, en général, il serait l'injection d'une référence qu'il vous serait se moquer.

C'est ce que je suis aujourd'hui si le résultat du test est produite de manière asynchrone.

public class TestUtil {

    public static <R> R await(Consumer<CompletableFuture<R>> completer) {
        return await(20, TimeUnit.SECONDS, completer);
    }

    public static <R> R await(int time, TimeUnit unit, Consumer<CompletableFuture<R>> completer) {
        CompletableFuture<R> f = new CompletableFuture<>();
        completer.accept(f);
        try {
            return f.get(time, unit);
        } catch (InterruptedException | TimeoutException e) {
            throw new RuntimeException("Future timed out", e);
        } catch (ExecutionException e) {
            throw new RuntimeException("Future failed", e.getCause());
        }
    }
}

À l'aide de statique des importations, le test de lit plutôt agréable.
(remarque, dans cet exemple, je vais partir un thread pour illustrer l'idée)

    @Test
    public void testAsync() {
        String result = await(f -> {
            new Thread(() -> f.complete("My Result")).start();
        });
        assertEquals("My Result", result);
    }

Si f.complete n'est pas appelée, le test échouera après un délai d'attente. Vous pouvez également utiliser f.completeExceptionally à l'échec tôt.

Si vous voulez tester la logique tout simplement pas le tester de manière asynchrone.

Par exemple pour tester ce code qui fonctionne sur les résultats d'une méthode asynchrone.

public class Example {
    private Dependency dependency;

    public Example(Dependency dependency) {
        this.dependency = dependency;            
    }

    public CompletableFuture<String> someAsyncMethod(){
        return dependency.asyncMethod()
                .handle((r,ex) -> {
                    if(ex != null) {
                        return "got exception";
                    } else {
                        return r.toString();
                    }
                });
    }
}

public class Dependency {
    public CompletableFuture<Integer> asyncMethod() {
        //do some async stuff       
    }
}

Dans le test se moquer de la dépendance synchrone mise en œuvre. L'unité de test est complètement synchrone et s'exécute en 150ms.

public class DependencyTest {
    private Example sut;
    private Dependency dependency;

    public void setup() {
        dependency = Mockito.mock(Dependency.class);;
        sut = new Example(dependency);
    }

    @Test public void success() throws InterruptedException, ExecutionException {
        when(dependency.asyncMethod()).thenReturn(CompletableFuture.completedFuture(5));

        //When
        CompletableFuture<String> result = sut.someAsyncMethod();

        //Then
        assertThat(result.isCompletedExceptionally(), is(equalTo(false)));
        String value = result.get();
        assertThat(value, is(equalTo("5")));
    }

    @Test public void failed() throws InterruptedException, ExecutionException {
        //Given
        CompletableFuture<Integer> c = new CompletableFuture<Integer>();
        c.completeExceptionally(new RuntimeException("failed"));
        when(dependency.asyncMethod()).thenReturn(c);

        //When
        CompletableFuture<String> result = sut.someAsyncMethod();

        //Then
        assertThat(result.isCompletedExceptionally(), is(equalTo(false)));
        String value = result.get();
        assertThat(value, is(equalTo("got exception")));
    }
}

Vous n'avez pas de tester le comportement asynchrone, mais vous pouvez tester si la logique est correcte.