Ein Test, um sicherzustellen, dass der von Ihnen geschriebene Code wie erwartet funktioniert. Wird auch als Unit-Test bezeichnet. JUnit ist ein sehr bekanntes Framework für Unit-Tests in Java. Das Schreiben von Testprogrammen unter Verwendung eines gemeinsamen Frameworks erleichtert anderen das Ändern ihrer Testprogramme.
https://stackoverflow.com/questions/19330832/setting-up-junit-with-intellij-idea https://www.slideshare.net/SatoshiKubo1/junitjava
Zur Bestätigung der Testergebnisse werden verschiedene Zusicherungen verwendet. assertEquals() → Stellen Sie fest, ob das erwartete Ergebnis mit dem tatsächlichen Ergebnis übereinstimmt. Argument 1: (erwartet, tatsächlich) Argument 2: (String-Nachricht, erwartet, aktuell) - Eine Nachricht wird angezeigt, wenn der Test fehlschlägt. Argument 3: (erwartet, tatsächlich, Delta) - Delta ist die Toleranz. Argument 4: (String-Nachricht, doppelt erwartet, doppelt tatsächlich, doppelt Delta) - assertNotNull() → Beurteilen Sie, ob das angegebene Objekt nicht null ist. Argument 1: (Objekt Objekt) Argument 2: (String-Nachricht, Objektobjekt) - Eine Nachricht wird angezeigt, wenn der Test fehlschlägt. assertNull() → Beurteilen Sie, ob das angegebene Objekt Null ist. Argument 1: (Objekt Objekt) Argument 2: (String-Nachricht, Objektobjekt) - Eine Nachricht wird angezeigt, wenn der Test fehlschlägt. assertSame() → Beurteilen Sie, ob sich die beiden angegebenen Objekte auf dasselbe Objekt beziehen. Argument 1: (Objekt erwartet, Objekt tatsächlich) Argument 2: (String-Nachricht, Objektobjekt) - Eine Nachricht wird angezeigt, wenn der Test fehlschlägt. assertTrue() → Beurteilen Sie, ob die angegebenen Bedingungen korrekt sind. Argument 1: (Objekt erwartet, Objekt tatsächlich) Argument 2: (String-Nachricht, Objektobjekt) - Eine Nachricht wird angezeigt, wenn der Test fehlschlägt. assertThat() In Kombination mit Matcher ist dies bequemer als assertEquals (). Da in einem Objekt nur ein equals () erstellt werden kann, hat assertEquals () seine Grenzen.
Argumente: (Objekt aktuell, Matcher-Matcher) Details
Die Methoden in der Testklasse werden nicht in der Reihenfolge von oben ausgeführt. Schreiben Sie daher keine Testmethoden, die die obigen Testergebnisse annehmen.
Erstellen Sie keine "Nebenwirkungen", die den Status des Systems ändern, z. B. das Aktualisieren der Datenbank, wenn Tests durchgeführt werden.
Damit diejenigen, die den Code später lesen, den Zweck des Tests schnell verstehen können.
Das gleiche wie oben. Einfach und leicht zu verstehen ohne Abfall.
Manuelles Schreiben + viele Fehler + schwer mit Updates Schritt zu halten.
Häufig und einfach testen zu können.
Wenn Sie zu Beginn und am Ende mehrerer Methoden eine allgemeine Verarbeitung (Verbinden / Trennen der Datenbank usw.) durchführen möchten, verwenden Sie die Methoden setUp () und tearDown (). setUp() Wird ausgeführt, bevor jede Testmethode aufgerufen wird. tearDown() Wird nach dem Ende jeder Testmethode ausgeführt.
Wie oben erwähnt, werden die Testmethoden nicht in der Reihenfolge ausgeführt, in der sie geschrieben wurden. Sie können jedoch die TestSuite-Klasse verwenden, um die Reihenfolge anzugeben, in der die Testmethoden ausgeführt werden.
Recommended Posts