Un test pour vous assurer que le code que vous écrivez fonctionne comme prévu. Aussi appelé test unitaire. JUnit est un framework très connu pour les tests unitaires en Java. L'écriture de programmes de test à l'aide d'un cadre commun permet aux autres de modifier plus facilement leurs programmes de test.
https://stackoverflow.com/questions/19330832/setting-up-junit-with-intellij-idea https://www.slideshare.net/SatoshiKubo1/junitjava
Diverses affirmations sont utilisées pour confirmer les résultats des tests. assertEquals() → Déterminez si le résultat attendu est le même que le résultat réel. Argument 1: (attendu, réel) Argument 2: (Message de chaîne, attendu, réel) --Un message s'affiche si le test échoue. Argument 3: (attendu, réel, delta) --delta est la tolérance. Argument 4: (Message de chaîne, double attendu, double réel, double delta) - assertNotNull() → Jugez si l'objet donné n'est pas nul. Argument 1: (objet objet) Argument 2: (message chaîne, objet objet) -Un message s'affiche si le test échoue. assertNull() → Jugez si l'objet donné est nul. Argument 1: (objet objet) Argument 2: (message chaîne, objet objet) -Un message s'affiche si le test échoue. assertSame() → Jugez si les deux objets donnés font référence au même objet. Argument 1: (objet attendu, objet réel) Argument 2: (message chaîne, objet objet) -Un message s'affiche si le test échoue. assertTrue() → Jugez si les conditions données sont correctes. Argument 1: (objet attendu, objet réel) Argument 2: (message chaîne, objet objet) -Un message s'affiche si le test échoue. assertThat() En combinaison avec Matcher, c'est plus pratique que assertEquals (). Il y a une limite à assertEquals () car un seul equals () peut être créé dans un objet. Puisque c'est Matcher, pas assertThat, qui est vérifié, il est hautement extensible. La situation d'écriture d'assert Equals sur plusieurs lignes ne se produit plus. Arguments: (Object actual, Matcher matcher) Détails
Les méthodes de la classe de test ne sont pas exécutées dans l'ordre à partir du haut. Par conséquent, n'écrivez pas de méthodes de test qui supposent les résultats de test ci-dessus.
Ne créez pas d '"effets secondaires" qui modifient l'état du système, comme la mise à jour de la base de données lors du test.
Pour que ceux qui liront le code plus tard puissent comprendre rapidement le but du test.
Comme ci-dessus. Simple et facile à comprendre sans gaspillage.
Ecrire manuellement + de nombreuses erreurs + difficile de suivre les mises à jour.
Pour pouvoir tester fréquemment et facilement.
Si vous souhaitez effectuer un traitement commun (connexion / déconnexion de la base de données, etc.) au début et à la fin de plusieurs méthodes, utilisez les méthodes setUp () et tearDown (). setUp() Exécuté avant l'appel de chaque méthode de test. tearDown() Exécuté après la fin de chaque méthode de test.
Comme mentionné ci-dessus, les méthodes de test ne sont pas exécutées dans l'ordre dans lequel elles sont écrites, mais vous pouvez utiliser la classe TestSuite pour spécifier l'ordre dans lequel les méthodes de test sont exécutées.
Recommended Posts