Comment faire pour exécuter la simultanéité de l'unité de test?

Malheureusement, je ne crois pas que vous pouvez définitivement prouver que votre code est thread-safe en utilisant le temps de le tester. Vous pouvez lancer autant de threads que vous le souhaitez contre elle, et il peut/ne peut pas passer en fonction sur le calendrier.

Peut-être vous devriez regarder quelques les outils d'analyse statique, comme PMD, qui peut déterminer la façon dont vous utilisez la synchronisation et d'identifier les problèmes d'utilisation.

Vous ne pouvez prouver la présence concomitante de bugs, pas de leur absence.

Cependant, vous pouvez écrire un test spécialisé coureur qui engendre plusieurs threads et appelle ensuite votre @Test annoté méthodes.

Cours d'exécution simultanément peut conduire à des résultats inattendus. Par exemple, je viens de découvrir, que, si mon Test de suite avec 200 tests de passe lors de l'exécution, un par un, il ne parvient pas pour l'exécution en simultané, j'ai creusé, et il n'était pas un thread de problème de sécurité, mais un test selon un autre, ce qui est une mauvaise chose et je pourrais résoudre le problème.

Mycila travail sur JUnit ConcurrentJunitRunner et ConcurrentSuite est très intéressant. L'article semble un peu obsolète par rapport à la dernière version GA, dans mes exemples, je vais vous montrer la mise à jour de l'utilisation.

L'annotation d'une classe de test comme suit causer à exécuter des méthodes d'essai simultanément, avec un niveau de simultanéité de 6:

import com.mycila.junit.concurrent.ConcurrentJunitRunner;
import com.mycila.junit.concurrent.Concurrency;

@RunWith(ConcurrentJunitRunner.class)
@Concurrency(6)
public final class ATest {
...

Vous pouvez également exécuter toutes les classes de test en parallèle:

import com.mycila.junit.concurrent.ConcurrentSuiteRunner;

@RunWith(ConcurrentSuiteRunner.class)
@Suite.SuiteClasses({ATest.class, ATest2.class, ATest3.class})
public class MySuite {
}

La Maven dependency est:

<dependency>
    <groupId>com.mycila</groupId>
    <artifactId>mycila-junit</artifactId>
    <version>1.4.ga</version>
</dependency> 

Je suis actuellement étudiant comment exécuter des méthodes plusieurs fois et en même temps avec ce package. Il peut être possible déjà, si quelqu'un a un exemple, laissez-moi savoir, en dessous de mon homebrewed solution.

@Test
public final void runConcurrentMethod() throws InterruptedException {
    ExecutorService exec = Executors.newFixedThreadPool(16);
    for (int i = 0; i < 10000; i++) {
        exec.execute(new Runnable() {
             @Override
             public void run() {
                 concurrentMethod();
             }
        });
    }
    exec.shutdown();
    exec.awaitTermination(50, TimeUnit.SECONDS);
}

private void concurrentMethod() {
    //do and assert something
}

Comme d'autres l'ont noté, c'est vrai que vous ne pouvez jamais être sûr de savoir si une simultanéité bug allait venir ou pas, mais avec des dizaines de milliers ou centaines de milliers d'exécutions, avec une simultanéité de, dire 16, la statistique est de votre côté.

Dans votre exemple, la méthode postMessage() est synchronisé, afin de ne pas voir réellement des effets secondaires de la concurrence au sein d'une même VM, mais vous pourriez être en mesure d'évaluer les performances de la version synchronisée.

Vous aurez besoin pour exécuter plusieurs copies du programme de test en même temps dans les différentes machines virtuelles. Vous pouvez utiliser

Si vous ne pouvez pas obtenir votre framework de test pour le faire, vous pouvez lancer certains VMs de votre auto.
Le processus générateur des choses est une douleur, avec des sentiers et autres joyeusetés, mais ici, c'est le général de l'esquisse:

Process running[] = new Process[5];
for (int i = 0; i < 5; i++) {
 ProcessBuilder b = new ProcessBuilder("java -cp " + getCP() + " MyTestRunner");
 running[i] = b.start();
}

for(int i = 0; i < 5; i++) {
 running[i].waitFor();
}

J'ai l'habitude de faire quelque chose comme cela pour la simple filetée tests, comme les autres ont publié, le test n'est pas une preuve de l'exactitude, mais il secoue idiot de bugs dans la pratique. Il permet de tester pendant un long moment sous une variété de conditions différentes, parfois des bogues de simultanéité prendre un certain temps à se manifester dans un test.

public void testMesageBoard() {
 final MessageBoard b = new MessageBoard();

 int n = 5;
 Thread T[] = new Thread[n];
 for (int i = 0; i < n; i++) {
  T[i] = new Thread(new Runnable() {
   public void run() {
    for (int j = 0; j < maxIterations; j++) {
      Thread.sleep( random.nextInt(50) );
      b.postMessage(generateMessage(j));
      verifyContent(j); //put some assertions here
    }
   }
  });

  PerfTimer.start();
  for (Thread t : T) {
   t.start();
  }

  for (Thread t : T) {
   t.join();
  }
  PerfTimer.stop();
  log("took: " + PerfTimer.elapsed());
 }
}**strong text**

Vous pouvez utiliser le programme tempus fugit bibliothèque pour exécuter des méthodes d'essai en parallèle et à plusieurs reprises pour simuler un test de charge type d'environnement. Bien qu'un précédent commentaire souligne que la méthode post est syncrhonised et donc protégé, membres associés ou méthodes peuvent être impliqués, et qui eux-mêmes ne sont pas protégés, de sorte que son possible qu'une charge /soak test de type pourrait attraper ces. Je vous suggère de vous installer un assez gros grains /de bout en bout comme test pour vous donner la meilleure chance d'attraper des trous de boucle.

Voir JUnit, la section intégration de la la documentation.

BTW, j'ai un développeur sur ce projet 🙂

La meilleure approche consiste à utiliser des tests de système pour faire sauter votre code avec des demandes pour voir si il tombe. Utilisez ensuite l'unité de test pour vérifier la logique de l'exactitude. La façon dont je voudrais cette approche est de créer un proxy pour l'appel asynchrone et l'ont fait de manière synchrone en cours de test.

Cependant, si vous vouliez faire cela à un autre niveau que l'installation complète et complète de l'environnement, vous pourriez le faire dans junit par la création de votre objet dans un thread séparé, puis de créer beaucoup de threads que le feu les demandes de votre objet et de bloquer le thread principal jusqu'à la fin. Cette approche peut faire des tests échouer par intermittence si vous n'avez pas l'obtenir.