it-swarm.com.de

Warum JUnit zum Testen verwenden?

Vielleicht ist meine Frage ein Neuling, aber ich kann die Umstände, unter denen ich junit verwenden würde, nicht wirklich verstehen?

Ob ich einfache oder größere Anwendungen schreibe, ich teste sie mit dem System.out Aussagen und es scheint mir ziemlich einfach.

Warum Testklassen mit JUnit erstellen, unnötige Ordner im Projekt, wenn wir immer noch die gleichen Methoden aufrufen müssen, überprüfen, was sie zurückgeben, und dann den Aufwand haben, alles zu kommentieren?

Warum schreibst du nicht eine Klasse und testest sie sofort mit System.out aber keine Testklassen erstellen?

PS. Ich habe noch nie an großen Projekten gearbeitet, die ich gerade lerne.

Wozu also?

130
Artem Moskalev

Das ist kein Test, sondern "manuelles Betrachten der Ausgabe" (im Unternehmen als LMAO bekannt). Formal ist es als "manuelles Suchen nach abnormaler Ausgabe" (LMFAO) bekannt. (Siehe Anmerkung unten)

Jedes Mal, wenn Sie Code ändern, müssen Sie die App und LMFAO für den gesamten Code ausführen, der von diesen Änderungen betroffen ist. Dies ist auch bei kleinen Projekten problematisch und fehleranfällig.

Skalieren Sie jetzt jedes Mal, wenn Sie einen Code ändern, auf 50k, 250k, 1m LOC oder mehr und LMFAO. Es ist nicht nur unangenehm, sondern auch unmöglich: Sie haben die Kombinationen von Eingaben, Ausgaben, Flags und Bedingungen vergrößert, und es ist schwierig, alle möglichen Zweige auszuüben.

Schlimmer noch: LMFAO kann bedeuten, Seiten über Seiten einer Web-App zu besuchen, Berichte zu erstellen, über Millionen von Protokollzeilen in Dutzenden von Dateien und Maschinen zu stöbern, generierte und zugestellte E-Mails zu lesen, Textnachrichten zu überprüfen, den Pfad eines Roboters zu überprüfen und eine Flasche zu füllen Soda, das Sammeln von Daten aus hundert Webdiensten, das Überprüfen des Prüfpfads einer Finanztransaktion ... Sie haben die Idee. "Ausgabe" bedeutet nicht ein paar Zeilen Text, "Ausgabe" bedeutet aggregiertes Systemverhalten.

Zuletzt Unit- und Verhaltenstests definieren Systemverhalten. Tests können von einem Continuous Integration Server ausgeführt und auf Richtigkeit überprüft werden. Sicher, so kann System.outs, aber der CI-Server wird nicht wissen, ob einer von ihnen falsch ist - und wenn ja, handelt es sich um Komponententests, und Sie können auch ein Framework verwenden.

Egal wie gut wir uns fühlen, Menschen sind keine guten Unit-Test-Frameworks oder CI-Server.


Anmerkung: LMAO is Testen, aber in einem sehr eingeschränkten Sinn. Es ist nicht in irgendeiner sinnvollen Weise über ein gesamtes Projekt oder als Teil eines Prozesses wiederholbar. Es ist vergleichbar mit einer schrittweisen Entwicklung in einer REPL, aber es formalisiert niemals diese inkrementellen Tests.

133
Dave Newton

Wir schreiben Tests, um die Richtigkeit des Verhaltens eines Programms zu überprüfen.

Das Überprüfen der Richtigkeit des Verhaltens eines Programms durch Überprüfen des Inhalts von Ausgabeanweisungen mit Ihren Augen ist ein Handbuch . oder genauer gesagt, ein visueller Prozess.

Das könnte man argumentieren

visuelle Inspektion funktioniert , ich überprüfe, ob der Code das tut, was er soll, für diese Szenarien und sobald ich sehe, dass es richtig ist, können wir loslegen.

Schön, dass Sie sich dafür interessieren, ob der Code richtig funktioniert oder nicht. Das ist gut. Sie sind der Kurve voraus! Leider gibt es Probleme mit diesem Ansatz.

Das erste Problem bei der Sichtprüfung besteht darin, dass Sie einen schweren Schweißunfall haben und nicht in der Lage sind, die Richtigkeit Ihres Codes erneut zu überprüfen.

Das zweite Problem ist, dass das verwendete Augenpaar eng mit dem Gehirn des Eigentümers der Augen gekoppelt ist. Wenn der Autor des Codes auch die im visuellen Inspektionsprozess verwendeten Augen besitzt, hängt der Prozess der Überprüfung der Korrektheit vom Wissen über das im Gehirn des visuellen Inspektors verinnerlichte Programm ab.

Es ist schwierig für ein neues Paar Augen, die Richtigkeit des Codes zu überprüfen, nur weil sie nicht mit dem Gehirn des ursprünglichen Programmierers zusammenarbeiten. Der Besitzer des zweiten Augenpaares muss sich mit dem ursprünglichen Autor des Codes unterhalten , um den fraglichen Code vollständig zu verstehen. Konversation als Mittel des Wissensaustauschs ist notorisch unzuverlässig. Ein Punkt, der strittig ist, wenn der Original-Coder für die neuen Augenpaare nicht verfügbar ist. In diesem Fall muss das neue Augenpaar den Originalcode lesen.

Das Lesen des Codes anderer Personen, der nicht durch Komponententests abgedeckt ist, ist schwieriger als das Lesen des Codes, der mit Komponententests verbunden ist. Im besten Fall ist das Lesen des Codes anderer Leute eine knifflige Aufgabe, im schlimmsten Fall ist dies die schwierigste Aufgabe in der Softwareentwicklung. Es gibt einen Grund, warum Arbeitgeber bei der Ausschreibung von Stellenangeboten betonen, dass ein Projekt auf der grünen Wiese (oder ganz neu) ist. Das Schreiben von Code von Grund auf ist einfacher als das Ändern von vorhandenem Code und lässt den ausgeschriebenen Job für potenzielle Mitarbeiter attraktiver erscheinen.

Beim Unit-Test teilen wir den Code in seine Bestandteile auf. Für jede Komponente legen wir dann unseren Stand fest, wie sich das Programm verhalten soll . Jeder Komponententest erzählt eine Geschichte darüber, wie sich dieser Teil des Programms in einem bestimmten Szenario verhalten sollte. Jeder Komponententest ist wie eine Klausel in einem Vertrag, die beschreibt, was aus Sicht des Kundencodes geschehen soll.

Dies bedeutet dann, dass ein neues Augenpaar zwei Stränge lebendiger und genauer Dokumentation zum jeweiligen Code.

Zuerst haben sie den Code selbst, die Implementierung, wie der Code gemacht wurde ; Zweitens haben sie alle Kenntnisse, die der ursprüngliche Codierer in einer Reihe von formalen Anweisungen beschrieben hat, die die Geschichte darüber erzählen, wie sich dieser Code verhalten soll.

Unit-Tests erfassen und beschreiben formal das Wissen, das der ursprüngliche Autor bei der Implementierung der Klasse besaß. Sie bieten eine Beschreibung des Verhaltens dieser Klasse bei Verwendung durch einen Client.

Es ist richtig, dass Sie die Nützlichkeit dieser Vorgehensweise in Frage stellen, da es möglich ist, Komponententests zu schreiben, die nutzlos sind, nicht den gesamten fraglichen Code abdecken, veraltet oder veraltet sind und so weiter. Wie stellen wir sicher, dass Unit-Tests nicht nur den Prozess eines sachkundigen, gewissenhaften Autors nachahmen, sondern ihn auch verbessern, indem sie die Ausgabeanweisungen ihres Codes zur Laufzeit visuell überprüfen? Schreiben Sie zuerst den Komponententest und dann den Code, um diesen Test zu bestehen. Wenn Sie fertig sind, lassen Sie die Computer die Tests ausführen. Sie sind schnell und können sich wiederholende Aufgaben ausführen. Sie sind ideal für den Job geeignet.

Stellen Sie die Testqualität sicher, indem Sie sie jedes Mal überprüfen, wenn Sie den zu testenden Code berühren, und die Tests für jeden Build ausführen. Wenn ein Test fehlschlägt, beheben Sie ihn sofort.

Wir automatisieren den Prozess der Ausführung von Tests, sodass diese bei jedem Build des Projekts ausgeführt werden. Wir automatisieren auch die Erstellung von Berichten zur Codeabdeckung, in denen der Prozentsatz des Codes angegeben ist, der durch Tests abgedeckt und ausgeführt wird. Wir streben hohe Prozentsätze an. Einige Unternehmen verhindern, dass Codeänderungen in die Quellcodeverwaltung eingecheckt werden, wenn nicht genügend Komponententests geschrieben wurden, um Änderungen im Verhalten des Codes zu beschreiben. In der Regel überprüft ein zweites Augenpaar Codeänderungen in Zusammenarbeit mit dem Autor der Änderungen. Der Prüfer wird durch die Änderungen sicherstellen, dass die Änderungen nachvollziehbar und durch Tests ausreichend abgedeckt sind. Der Überprüfungsprozess ist also manuell, aber wenn die Tests (Unit- und Integrationstests und möglicherweise Benutzerakzeptanztests) diesen manuellen Überprüfungsprozess bestehen, werden sie Teil des automatischen Erstellungsprozesses. Diese werden jedes Mal ausgeführt, wenn eine Änderung eingecheckt wird. Ein Continuous-Integration Server führt diese Aufgabe im Rahmen des Erstellungsprozesses aus.

Tests, die automatisch ausgeführt werden, gewährleisten die Integrität des Verhaltens des Codes und tragen dazu bei , dass zukünftige Änderungen an der Codebasis den Code nicht beschädigen .

Schließlich können Sie durch das Bereitstellen von Tests aggressiv Code neu faktorisieren vorgehen, da Sie große Code-Verbesserungen sicher durchführen können, wenn Sie wissen, dass Ihre Änderungen vorhandene Tests nicht beschädigen.

Es gibt eine Einschränkung bei Test Driven Development und das heißt, Sie müssen Code mit dem Auge schreiben, um ihn testbar zu machen. Dies beinhaltet das Codieren in Schnittstellen und die Verwendung von Techniken wie Abhängigkeitsinjektion, um zusammenarbeitende Objekte zu instanziieren. Schauen Sie sich die Arbeit von Kent Beck an, der TDD sehr gut beschreibt. Schauen Sie nach Kodierung für Schnittstellen und studieren Sie Entwurfsmuster

50
Rob Kielty

Wenn Sie mit so etwas wie System.out testen, testen Sie nur einen kleinen Teil der möglichen Anwendungsfälle. Dies ist nicht sehr gründlich, wenn Sie es mit Systemen zu tun haben, die nahezu unendlich viele verschiedene Eingaben akzeptieren können.

Unit-Tests wurden entwickelt, um Ihnen das schnelle Ausführen von Tests für Ihre Anwendung mit einer sehr großen und vielfältigen Menge unterschiedlicher Dateneingaben zu ermöglichen. Darüber hinaus berücksichtigen die besten Komponententests auch Grenzfälle, z. B. die Dateneingaben, die direkt am Rand dessen liegen, was als gültig angesehen wird.

Für einen Menschen kann es Wochen dauern, alle diese verschiedenen Eingaben zu testen, während es für eine Maschine Minuten dauern kann.

Stellen Sie sich das so vor: Sie "testen" auch nichts, was statisch ist. Ihre Anwendung wird höchstwahrscheinlich ständig geändert. Daher sind diese Komponententests so konzipiert, dass sie zu verschiedenen Zeitpunkten im Kompilierungs- oder Bereitstellungszyklus ausgeführt werden. Der vielleicht größte Vorteil ist:

Wenn Sie irgendetwas in Ihrem Code kaputtmachen, werden Sie darüber informiert im Moment, nicht nachdem Sie bereitgestellt haben, nicht wenn ein QA-Tester einen Fehler entdeckt hat, nicht wenn Ihre Kunden abgebrochen haben. Sie haben auch eine bessere Chance, den Fehler zu beheben sofort, da es klar ist, dass das, was den fraglichen Teil des Codes gebrochen hat, höchstwahrscheinlich seit Ihrer letzten Kompilierung passiert ist. Somit wird der Umfang der zur Behebung des Problems erforderlichen Nachforschungen erheblich reduziert.

13
jmort253

Unit-Tests stellen sicher, dass der Code wie vorgesehen funktioniert. Sie sind auch sehr hilfreich, um sicherzustellen, dass der Code weiterhin wie vorgesehen funktioniert, falls Sie ihn später ändern müssen, um neue Funktionen zur Behebung eines Fehlers zu erstellen. Durch eine hohe Testabdeckung Ihres Codes können Sie Funktionen weiterentwickeln, ohne viele manuelle Tests durchführen zu müssen.

Ihr manueller Ansatz mit System.out Ist gut, aber nicht der beste. Dies ist ein einmaliger Test, den Sie durchführen. In der Praxis ändern sich die Anforderungen ständig, und die meiste Zeit nehmen Sie zahlreiche Änderungen an vorhandenen Funktionen und Klassen vor. Also ... nicht jedes Mal, wenn Sie den bereits geschriebenen Code testen.

es gibt auch einige erweiterte Funktionen, die in JUnit gefällt

Behaupten Sie Aussagen

JUnit bietet Methoden zum Testen auf bestimmte Bedingungen. Diese Methoden beginnen in der Regel mit Asserts und ermöglichen es Ihnen, die Fehlermeldung, das erwartete und das tatsächliche Ergebnis anzugeben

Einige dieser Methoden sind

  1. fail([message]) - Lässt den Test fehlschlagen. Kann verwendet werden, um zu überprüfen, ob ein bestimmter Teil des Codes nicht erreicht wird. Oder einen fehlerhaften Test durchzuführen, bevor der Testcode implementiert wird.
  2. assertTrue(true)/assertTrue(false) - Wird immer wahr/falsch sein. Kann zur Vorgabe eines Testergebnisses verwendet werden, wenn der Test noch nicht implementiert ist.
  3. assertTrue([message,] condition) - Überprüft, ob der boolesche Wert condition wahr ist.
  4. assertEquals([message,] expected, actual) - Prüft, ob zwei Werte gleich sind (nach der Methode equals, falls implementiert, ansonsten mit dem Referenzvergleich ==). Hinweis: Bei Arrays wird die Referenz geprüft und nicht der Inhalt, verwenden Sie dazu assertArrayEquals([message,] expected, actual).
  5. assertEquals([message,] expected, actual, delta) - Prüft, ob zwei float- oder double-Werte in einem bestimmten Abstand voneinander liegen, gesteuert durch den Wert delta.
  6. assertNull([message,] object) - Überprüft, ob das Objekt null ist

und so weiter. Alle Beispiele finden Sie im vollständigen Javadoc hier .

Suiten

Mit Testsuiten können Sie in gewisser Weise kombinieren mehrere Testklassen zu einer einzigen Einheit zusammenfassen, sodass Sie sie alle gleichzeitig ausführen können. Ein einfaches Beispiel, das die Testklassen MyClassTest und MySecondClassTest in einer Suite namens AllTests kombiniert:

import org.junit.runner.RunWith;
import org.junit.runners.Suite;
import org.junit.runners.Suite.SuiteClasses;

@RunWith(Suite.class)
@SuiteClasses({ MyClassTest.class, MySecondClassTest.class })
public class AllTests { } 
9
Arvind

Ich habe ein anderes System hinzugefügt.

  • Machen Sie jeden Testfall unabhängig (Es ist wichtig)

    JUnit schafft das: Jedes Mal, wenn eine neue Testfallinstanz erstellt wird und @Before wird genannt.

  • Trennen Sie den Testcode von der Quelle

    JUnit kann das.

  • Integration mit CI

    JUnit schafft das mit Ant und Maven.

  • Ordnen und kombinieren Sie Testfälle einfach

    JUnit kann @Ignore und Testsuite.

  • Leicht zu überprüfendes Ergebnis

    JUnit bietet viele Assert-Methoden (assertEquals, assertSame...)

  • Mock und Stub sorgen dafür, dass Sie sich auf das Testmodul konzentrieren.

    JUnit kann Folgendes tun: Mithilfe von Mock und Stub können Sie das richtige Gerät einrichten und sich auf die Logik des Testmoduls konzentrieren.

Der Hauptvorteil von JUnit ist, dass es automatisiert ist, anstatt dass Sie manuell mit Ihren Ausdrucken nachsehen müssen. Jeder Test, den Sie schreiben, bleibt bei Ihrem System. Wenn Sie also eine Änderung vornehmen, die einen unerwarteten Nebeneffekt hat, wird sie von Ihrem Test abgefangen und schlägt fehl, anstatt dass Sie daran denken müssen, nach jeder Änderung alles manuell zu testen.

6
n00begon

JUnit ist ein Unit-Test-Framework für die Programmiersprache Java=). Es ist wichtig für die testgetriebene Entwicklung und gehört zu einer Familie von Unit-Test-Frameworks, die zusammen als xUnit bezeichnet werden.

JUnit fördert die Idee des "Erst Testens, dann Codieren", wobei der Schwerpunkt auf dem Einrichten der Testdaten für einen Code liegt, der zuerst getestet und dann implementiert werden kann. Dieser Ansatz ist wie "ein wenig testen, ein wenig programmieren, ein wenig testen, ein wenig programmieren ...", der die Produktivität des Programmierers und die Stabilität des Programmiercodes erhöht, wodurch der Stress des Programmierers und die für das Debuggen aufgewendete Zeit verringert werden.

Features JUnit ist ein Open-Source-Framework, das zum Schreiben und Ausführen von Tests verwendet wird.

Enthält eine Anmerkung zur Identifizierung der Testmethoden.

Bietet Aussagen zum Testen der erwarteten Ergebnisse.

Stellt Testläufer zum Ausführen von Tests bereit.

Mit JUnit-Tests können Sie Code schneller schreiben, was die Qualität erhöht

JUnit ist elegant einfach. Es ist weniger komplex und braucht weniger Zeit.

JUnit-Tests können automatisch ausgeführt werden und sie überprüfen ihre eigenen Ergebnisse und geben sofortiges Feedback. Es ist nicht erforderlich, einen Bericht mit Testergebnissen manuell durchzukämmen.

JUnit-Tests können in Testsuiten organisiert werden, die Testfälle und sogar andere Testsuiten enthalten.

Junit zeigt den Testfortschritt in einer grünen Leiste an, wenn der Test erfolgreich ist, und wird rot, wenn ein Test fehlschlägt.

4
AKKI

Ich habe eine etwas andere Perspektive, warum JUnit benötigt wird.

Sie können tatsächlich alle Testfälle selbst schreiben, aber es ist umständlich. Hier sind die Probleme:

  1. Anstelle von System.out Können wir if(value1.equals(value2)) hinzufügen und 0 oder -1 oder eine Fehlermeldung zurückgeben. In diesem Fall benötigen wir eine "Haupt" -Testklasse, die alle diese Methoden ausführt und die Ergebnisse überprüft und festhält, welche Testfälle fehlgeschlagen sind und welche bestanden wurden.

  2. Wenn Sie weitere Tests hinzufügen möchten, müssen Sie diese ebenfalls zu dieser "Haupt" -Testklasse hinzufügen. Änderungen an vorhandenem Code. Wenn Sie Testfälle aus Testklassen automatisch erkennen möchten, müssen Sie Reflection verwenden.

  3. Alle Ihre Tests und Ihre Hauptklasse zum Ausführen von Tests werden von Eclipse nicht erkannt, und Sie müssen benutzerdefinierte Debug-/Ausführungskonfigurationen schreiben, um diese Tests auszuführen. Sie sehen diese hübschen grün/rot gefärbten Ausgänge jedoch immer noch nicht.

Folgendes macht JUnit:

  1. Es hat assertXXX() Methoden, die nützlich sind, um hilfreiche Fehlermeldungen aus den Bedingungen auszudrucken und Ergebnisse an die "Haupt" -Klasse zu übermitteln.

  2. Die "Haupt" -Klasse heißt runner und wird von JUnit bereitgestellt, sodass wir keine schreiben müssen. Und es erkennt die Prüfmethoden automatisch durch Reflektion. Wenn Sie neue Tests mit der Annotation @Test Hinzufügen, werden diese automatisch erkannt.

  3. JUnit verfügt auch über eine Eclipse-Integration und eine Maven/Gradle-Integration, so dass es einfach ist, Tests auszuführen und Sie keine benutzerdefinierten Laufkonfigurationen schreiben müssen.

Ich bin kein Experte für JUnit, das habe ich jetzt verstanden und werde in Zukunft noch mehr hinzufügen.

2
Sreekar

Sie können keinen Testfall schreiben, ohne das Testframework zu verwenden. Andernfalls müssen Sie Ihren Testframewok schreiben, um Ihren Testfällen gerecht zu werden. Hier sind einige Informationen zu JUnit Framework, ansonsten können Sie TestNG Framework verwenden.

Was ist Junit?

Junit ist zusammen mit Java Programming Language) ein weit verbreitetes Testframework. Sie können dieses Automatisierungsframework sowohl für Unit-Tests als auch für UI-Tests verwenden. Es hilft uns, den Ablauf der Ausführung unseres Codes mit verschiedenen Annotationen zu definieren. Junit basiert auf der Idee, zuerst zu testen und dann zu codieren, was uns hilft, die Produktivität von Testfällen und die Stabilität des Codes zu steigern.

Wichtige Funktionen von Junit Testing -

  1. Es ist ein Open-Source-Testframework, mit dem Benutzer Testfälle effektiv schreiben und ausführen können.
  2. Bietet verschiedene Arten von Anmerkungen, um Testmethoden zu identifizieren.
  3. Bietet verschiedene Arten von Zusicherungen, um die Ergebnisse der Testfallausführung zu überprüfen.
  4. Es gibt auch Testläufer zum effektiven Ausführen von Tests.
  5. Es ist sehr einfach und spart somit Zeit.
  6. Es bietet Möglichkeiten, Ihre Testfälle in Form von Testanzügen zu organisieren.
  7. Es gibt Testfallergebnisse auf einfache und elegante Weise.
  8. Sie können jUnit in Eclipse, Android Studio, Maven & Ant, Gradle und Jenkins integrieren
1
anuja jain

JUNI: BEOBACHTEN UND EINSTELLEN

Hier ist meine Perspektive von JUNIT.

JUNIT kann verwendet werden, um
1) Beobachten Sie ein Systemverhalten, wenn eine neue Einheit zu diesem System hinzugefügt wird.
2) Nehmen Sie Anpassungen im System vor, um die "neue" Einheit im System aufzunehmen.
Was? Genau.

Reales Leben zB.

Wenn Ihr Verwandter Ihr College Hostel Zimmer besucht,
1) Sie geben vor, verantwortungsbewusster zu sein.
2) Sie werden alles dort aufbewahren, wo es sein sollte, wie Schuhe im Schuhregal, nicht auf dem Stuhl, Kleidung im Schrank, nicht auf dem Stuhl.
3) Du wirst alles Schmuggelware los.
4) Sie starten die Bereinigung in jedem Gerät, das Sie besitzen.

In Bezug auf die Programmierung

System: Ihr Code
UNIT: Neue Funktionalität.
Als JUNIT-Framework wird für Java language verwendet, also JUNIT = Java UNIT (May be)).

Angenommen, Sie haben bereits einen gut kugelsicheren Code, aber eine neue Anforderung ist eingetroffen, und Sie müssen die neue Anforderung in Ihren Code einfügen. Diese neue Anforderung kann Ihren Code für einige Eingaben (Testfall) beschädigen.

Eine einfache Möglichkeit, diese Änderung anzupassen, ist das Testen von Einheiten (JUNIT).
Dazu sollten Sie beim Erstellen Ihrer Codebasis mehrere Testfälle für Ihren Code schreiben. Und bei jeder neuen Anforderung führen Sie einfach alle Testfälle aus, um festzustellen, ob ein Testfall fehlschlägt. Wenn Nein, sind Sie ein BadA ** -Künstler und können den neuen Code bereitstellen.
Wenn einer der Testfälle fehlschlägt, ändern Sie Ihren Code und führen die Testfälle erneut aus, bis Sie den grünen Status erhalten.

0
Rohit Singh

JUNIT ist die Methode, die normalerweise von Java) Entwicklern akzeptiert wird. Wenn sie ähnliche erwartete Eingaben für die Funktion liefern und dementsprechend entscheiden können, dass der geschriebene Code perfekt geschrieben ist oder wenn der Testfall fehlschlägt, kann auch ein anderer Ansatz gewählt werden müssen implementiert werden. JUNIT wird die Entwicklung beschleunigen und die 0 Fehler in der Funktion sicherstellen.

0
mohit sarsar

Unit-Tests werden mit der White-Box-Testmethode durchgeführt. Beim White-Box-Test handelt es sich um eine Methode zum Testen von Software, mit der interne Strukturen oder Funktionen einer Anwendung getestet werden.

Wann wird es aufgeführt? Unit Testing ist die erste Stufe des Softwaretests und wird vor dem Integrationstest durchgeführt.

https://onlyfullstack.blogspot.com/2019/02/junit-tutorial.html

https://onlyfullstack.blogspot.com/2019/02/what-is-junit-how-to-use-junit.html

0
Saurabh Oza