27. Didacticiel de l'échantillonneur JUnit

Ce didacticiel tente d'expliquer la conception de base, les fonctionnalités et l'utilisation du nouvel échantillonneur JUnit pour JMeter. L'échantillonneur a été introduit dans la version 2.1.2 de JMeter. Les versions antérieures n'ont pas l'échantillonneur.

27.1 Conception

L'implémentation actuelle prend en charge la convention et les extensions JUnit standard, comme oneTimeSetUp et oneTimeTearDown . D'autres fonctionnalités peuvent être ajoutées sur demande. L'échantillonneur fonctionne comme le JavaSampler avec quelques différences.

  • Plutôt que d'utiliser l'interface de test de JMeter, il analyse les fichiers jar pour les classes étendant la classe TestCase de JUnit . Cela signifie n'importe quelle classe ou sous-classe.
  • Les fichiers jar de test JUnit sont copiés dans jmeter/lib/junit au lieu de jmeter/lib
  • L'échantillonneur JUnit n'utilise pas de paires nom/valeur pour la configuration. L'échantillonneur suppose que setUp et tearDown configureront le test correctement.
    Remarque : les méthodes setUp et tearDown doivent être déclarées public afin que JMeter puisse l'utiliser.
  • L'échantillonneur mesure le temps écoulé uniquement pour la méthode de test et n'inclut pas setUp et tearDown .
  • Chaque fois que la méthode de test est appelée, JMeter transmettra le résultat aux écouteurs.
  • La prise en charge de oneTimeSetUp et oneTimeTearDown se fait en tant que méthode. Étant donné que JMeter est multi-thread, nous ne pouvons pas appeler oneTimeSetUp / oneTimeTearDown de la même manière que maven le fait.
  • L'échantillonneur signale les exceptions inattendues comme des erreurs.

27.2 Fonctionnalité

Voici une description de la fonctionnalité.

Nom
nom de l'échantillon. C'est la même chose que tous les échantillonneurs JMeter.
Filtre de paquet
fournit un moyen de filtrer les classes par nom de package.
Nom du cours
le nom de la classe à tester. L'échantillonneur analysera les fichiers jar dans jmeter/lib/ext et jmeter/lib/junit pour les classes étendant TestCase de JUnit .
Chaîne de constructeur
une chaîne à transmettre au constructeur de chaîne de la classe de test.
Méthode d'essai
le nom de la méthode à tester dans l'échantillonneur.
Message de réussite
un message descriptif indiquant ce que signifie le succès.
Code de réussite
un code unique indiquant que le test a réussi.
Message d'échec
un message descriptif indiquant ce que signifie un échec.
Code d'échec
un code unique indiquant que le test a échoué
Message d'erreur
une description des erreurs
Code d'erreur
un code pour les erreurs. N'a pas besoin d'être unique
Ne pas appeler setUp et tearDown
configurez l'échantillonneur pour qu'il n'appelle pas setUp et tearDown . Par défaut, setUp et tearDown doivent être appelés. Ne pas appeler ces méthodes pourrait affecter le test et le rendre inexact. Cette option doit être utilisée avec prudence.
Si la méthode sélectionnée est oneTimeSetUp ou oneTimeTearDown , cette option doit être cochée.
Ajouter une erreur d'assertion
Par défaut, l'échantillonneur n'ajoute pas les échecs d'assertion au message d'échec. Pour voir le message dans l'arborescence des résultats, cochez l'option.
Ajouter une exception d'exécution
Par défaut, l'échantillonneur n'ajoute pas les exceptions au message d'échec. Pour voir le stacktrace, cochez l'option
Requête JUnit
Requête JUnit

L'implémentation actuelle de l'échantillonneur essaiera d'abord de créer une instance en utilisant le constructeur de chaîne. Si la classe de test ne déclare pas de constructeur de chaîne, l'échantillonneur recherchera un constructeur vide. Exemple ci-dessous :

Exemples de constructeurs
Constructeur vide :
public class myTestCase {
  public myTestCase() {}
}
Constructeur de chaînes :
public class myTestCase {
  public myTestCase(String text) {
    super(texte);
  }
}

Par défaut, JMeter fournira des valeurs par défaut pour le code de réussite/échec et le message. Les utilisateurs doivent définir un ensemble de codes de réussite et d'échec uniques et les utiliser uniformément dans tous les tests.

27.3 Utilisation

Voici un petit pas à pas.

  1. Rédigez votre test JUnit et lancez les classes
  2. Copiez et collez les fichiers jar dans le répertoire jmeter/lib/ junit
  3. Démarrer JMeter
  4. Sélectionnez le plan de test
  5. Clic droit Ajouter  →  Groupe de threads
  6. Sélectionner le groupe de threads
  7. Clic droit Ajouter  →  Sampler  →  JUnit Request
  8. Entrez mon test unitaire dans le nom
  9. Entrez le package de votre test JUnit
  10. Sélectionnez la classe que vous souhaitez tester
  11. Sélectionnez une méthode à tester
  12. Entrez le test réussi dans le message de réussite
  13. Entrez 1000 dans le code de réussite
  14. Entrez le test a échoué dans le message d'échec
  15. Entrez 0001 dans le code d'échec
  16. Sélectionnez le groupe de threads
  17. Cliquez avec le bouton droit sur Ajouter  →  Écouteur  →  Afficher l'arborescence des résultats

L'un des avantages de l'échantillonneur JUnit est qu'il permet à l'utilisateur de sélectionner n'importe quelle méthode parmi une variété de tests unitaires pour créer un plan de test. Cela devrait réduire la quantité de code qu'un utilisateur doit écrire pour créer une variété de scénarios de test. À partir d'un ensemble de base de méthodes de test, différentes séquences et tests peuvent être créés à l'aide de l'interface graphique de JMeter.

Par exemple:

Plan d'essai1

TestCase1.testImportCustomer
TestCase2.testUpdateRandomCustomer
TestCase1.testSelect100
TestCase2.testUpdateOrder
TestCase1.testSelect1000

TestPlan2

TestCase1.testImportCustomer
TestCase1.testSelect100
TestCase1.testSelect1000
TestCase2.testAdd100Customers

27.4 Directives générales

Voici quelques directives générales pour écrire des tests JUnit afin qu'ils fonctionnent bien avec JMeter. Étant donné que JMeter fonctionne en multithread, il est important de garder certaines choses à l'esprit.

  • Écrivez les méthodes setUp et tearDown afin qu'elles soient thread-safe. Cela signifie généralement éviter d'utiliser des membres statiques.
  • Faites en sorte que les méthodes de test soient des unités de travail discrètes et non de longues séquences d'actions. En gardant la méthode de test à une opération discrète, il est plus facile de combiner des méthodes de test pour créer de nouveaux plans de test.
  • Évitez de faire dépendre les méthodes de test les unes des autres. Étant donné que JMeter permet le séquençage arbitraire des méthodes de test, le comportement d'exécution est différent du comportement par défaut de JUnit.
  • Si une méthode de test est configurable, faites attention à l'endroit où les propriétés sont stockées. Il est recommandé de lire les propriétés du fichier Jar.
  • Chaque échantillonneur crée une instance de la classe de test, alors écrivez votre test pour que la configuration se fasse dans oneTimeSetUp et oneTimeTearDown .
  • Si vous sélectionnez une classe et qu'aucune méthode ne s'affiche, cela signifie que l'échantillonneur a rencontré un problème lors de la création d'une instance de la classe de test. La meilleure façon de déboguer cela est d'ajouter un System.out à votre constructeur de classe et de voir ce qui se passe.
Go to top