JUnit: Vorschläge/ Best Practice

[Airwolf89]

Hallo Leute,

ich habe ein kleines Problemchen. Ich bin für ne Weile bei nem Kunden der ne ziemlich große Java Applikation hat und automatisierte Tests einführen will.

Das Problem ist, eigentlich haben wir alle keine Ahnung davon wie man das so macht

Ich hab mich schon in der Vergangenheit immer mal ein wenig mit JUnit beschäftigt und ein wenig rumprobiert, von daher weiß ich zumindest grundsätzlich wie JUnit funktioniert.
Allerdings ist mein Eindruck von meinen bisherigen Erfahrungen her der dass ich mit JUnit ganz gut einfache Sachen testen kann, also Zahlen oder booleans als Rückgabewert habe und diese Werte entsprechend mit den assert Methoden gegen andere Werte testen kann.
Das Projekt hingegen ist eher darauf ausgelegt Werte per XML und anderen Formaten entgegenzunehmen, damit ein wenig zu arbeiten und die in die Datenbank zu schreiben. Die meisten Methoden sind dabei Void Methoden. Das Projekt ist als Server Applikation (mit ner Swing Gui) ausgelegt und größtenteils mit Enterprise Java Beans und anderen Techniken gebaut in denen ich nicht allzuviel Erfahrung habe =)

Jetzt ist die Frage, wie testet man so eine Applikation bzw. in welcher Art und Weise ist es sinnvoll so eine Applikation automatisiert zu testen? Erster Anlaufpunkt soll sein den Datenimport automatisiert zu testen, später sollen auch automatische GUI Tests gebaut werden. Allerdings hab ich keine wirkliche Idee wie ich da rangehen sollte.
Es gibt schon ein paar Testklassen, die aus meiner Perspektive nicht vollständig und relativ zusammenhangslos aufgebaut und auch schon einige Jahre alt sind. Derjenige der die früher gebaut hat ist natürlich nicht mehr verfügbar. So wie ich das bisher rauslesen konnte, hat er im Endeffekt die Testcases so gebaut dass er ganze Prozesse (z.B. Datenimport) halt anstößt und nur die Exceptions abfängt, treten keine auf war der Test erfolgreich. Wäre an der Stelle auch erstmal mein erster Ansatz, aber ich denke dass es da doch noch bessere Möglichkeiten geben muss sowas zu testen.
Des weiteren bin ich auch nicht lange bei dem Kunden und soll quasi die Vorarbeit leisten und die Grundlage für eine automatisierte Testumgebung legen.

Ich will hier an der Stelle natürlich keine konkrete Hilfe mit der Anwendung selber, sondern würde gern von euren Erfahrungen lernen wie man so eine Aufgabe angehen kann, auf was man vielleicht achten sollte und was an der Stelle sinnvoll ist. Ich hoffe dass es hier ein paar Leute gibt die mir da ein paar Tipps geben könnten.

Meine erste Idee war, dass ich so ne Art zentrale Test-Applikation baue. Wir haben in der letzten Zeit schon ein paar kleinere Test-Tools gebaut die ich schon in dieser Applikation zusammengefasst habe. Nun war meine Idee so ne Art Framework zu bauen mit dem man dann modular die einzelnen Testsuites und TestCases in diese Applikation nach und nach einbauen kann. Allerdings scheint es nicht sehr verbreitet zu sein und auch keine wirklichen Möglichkeiten geben JUnit Tests über ne eigene GUI laufen zu lassen.

Also, was meint ihr? Wie würdet ihr so eine Aufgabe angehen?

Ich hoffe ihr könnt mir helfen.

Danke im voraus.

Grüße

 

[kama]

Hi,

ich fange mal hinten an:

Des weiteren bin ich auch nicht lange bei dem Kunden und soll quasi die Vorarbeit leisten und die Grundlage für eine automatisierte Testumgebung legen.

Es soll eine Umgebung aufgebaut werden für Tests wo ihr noch nicht mal wisst wie man richtig testet?
Ich scheint den Unterschied zwischen Unit- und Integrationstest nicht zu kennen....Kennst Du denn die Anforderungen für eine solche Umgebung ?

Hier scheinen zuerst einmal richtige Grundlagen gefragt zu sein. Wie schreibt man Unit Tests ? Oft benötigt man dazu Mocking Frameworks wie z.B. Mockito, JMockit etc. Damit kann man schon eine Menge anfangen..wenn man das Verstanden hat...Dann Integrationstests: Was ist das überhaupt und womit schreibt man die (Nein nicht mit JUnit!).

Das Problem wird sein, dass einen vorhandene Applikation die nicht mit Tests geschrieben wurde Refaktorisiert werden muss damit Sie testbar wird bzw. bleibt...und das ist nicht einfach....Das ist genau genommen eine Katze die sich in den Schwanz beißt...

Es gibt schon ein paar Testklassen, die aus meiner Perspektive nicht vollständig und relativ zusammenhangslos aufgebaut und auch schon einige Jahre alt sind.

Finde ich lustig...jemand der anscheinend keine Ahnung hat übt kritik...Da schlage ich einmal vor...erst besser machen und dann Meckern...;-)

Laufen die denn automatisch ?

Derjenige der die früher gebaut hat ist natürlich nicht mehr verfügbar. So wie ich das bisher rauslesen konnte, hat er im Endeffekt die Testcases so gebaut dass er ganze Prozesse (z.B. Datenimport) halt anstößt und nur die Exceptions abfängt, treten keine auf war der Test erfolgreich.

Ist eine Herangehensweise...nicht immer die Beste...abgesehen davon, ist das sehr schwer aufzubauen (Test Daten zu erstellen und zu Pflegen) und vor allem sehr Aufwendig und aktuell zu halten...und der ROI kommt immer erst sehr spät...

Man sollte sich mal den XML Import Teil genau anschauen ? Frameworks benutzt oder ist der Parser etc. selbst gehackt ? Wie kommen die Daten in die DB (Framework: Hibernate, Eclipselink JPA? oder per JDBC mit hand geklöppelt...) ?

Das Projekt hingegen ist eher darauf ausgelegt Werte per XML und anderen Formaten entgegenzunehmen, damit ein wenig zu arbeiten und die in die Datenbank zu schreiben. Die meisten Methoden sind dabei Void Methoden. Das Projekt ist als Server Applikation (mit ner Swing Gui) ausgelegt und größtenteils mit Enterprise Java Beans und anderen Techniken gebaut in denen ich nicht allzuviel Erfahrung habe =)

Ist es jetzt eine Server Applikation ? Applikation Server (JBoss, Oracle 4 J, Websphere, WebLogic, Glassfish etc.) ?
Ich verstehe das so, dass es einen GUI Teil gibt (in Swing) der mit der Server Applikation "redet" ? Ansonsten mach der Satz überhaupt keinen Sinn...Eine Server Applikation hat keine GUI...

So und wieder "nicht allzuviel Erfahrung"....und dann sollt Ihr Tests/Konzepte/Umgebungen aufbauen...Hm...also bezahlte Lernzeit beim Kunden....

Ich lese auch häufiger "automatisierte Tests"...habt Ihr überhaupt einen automatischen Build (Ant, Maven, Gradle etc.) so mit Continious Integration Server etc. Ich hoffe mal dass eine Versionskontrolle Verwendung findet...Habt Ihr denn auch entsprechende Testsysteme zur Verfügung ...

Nun jetzt zu den "Erfahrungen"...Ja mit JUnit schreibt man einfache Tests...deshalb sind es Unit Tests...Ich würde mich mal sehr intensiv mit dem Thema Testen beschäftigen und vor allem mal sehr viele Tests schreiben...(sprich in die Tasten hauen..)...Wenn ein Unit Tests kompliziert wird dann macht man was falsch...

...ne ziemlich große Java Applikation hat und automatisierte Tests einführen will.

Da wäre die erste Frage: Was ist "ziemlich große" ? Kannst Du mal eine Größenordnung LOC etc. geben?

Wieviele Entwickler sind daran beteiligt ? 5, 10, 100 oder mehr ?

Weiterhin hat hier jemand das Thema grundlegend misverstanden. Tests kann man nicht einführen die muss man machen...sprich in die Entwicklung integrieren und über die Zeit ausbauen...Das heißt neuer Code nur mit entsprechenden Tests...muss auch durchgesetzt werden...Machen die Entwickler dass denn ? Ich vermute das Nein...D

Tests einzuführen bedeutet am Anfang wenige Code Output sprich weniger Features etc.

Habt Ihr Metriken die die "Code Qualität" (Code Coverage mal als einfachstest Mittel) messen ? (Abgesehen von Style Guide etc.) abgesehen...


UnitTest


Gruß
Karl Heinz Marbaise

 

[Ruzmanz]

Ist eine Herangehensweise...nicht immer die Beste...abgesehen davon, ist das sehr schwer aufzubauen (Test Daten zu erstellen und zu Pflegen) und vor allem sehr Aufwendig und aktuell zu halten...und der ROI kommt immer erst sehr spät...

Nenne mir bitte einen Fall, wo die Vorgehensweise nicht die Beste ist? Wenn das Programm nicht ohne Fehler durchlaufen kann, dass sind die Unit-Tests, etc. total irrelevant. Simples Beispiel: Copy & Paste Fehler, wodurch im zweiten Abschnitt immer eine NullPointerException geworfen wird. Als Entwickler hat man meiner Meinung nach IMMER die Verpflichtung den Code manuell zu starten und zumindest einmal vom Anfang bis zum Ende durchlaufen zu lassen. Eine zuverlässige Automatisierung des Prozesses geht auch in Ordnung ... es muss nur passieren.

Okey, ich muss zugeben, dass ich im ersten Moment auf die Frage reingefallen ist. Die ist wie ein Fischköder, wo man einfach zuschnappt ...

Ich bin für ne Weile bei nem Kunden der ne ziemlich große Java Applikation hat und automatisierte Tests einführen will.

... Warum will der Kunde automatisierte Tests einführen?

"Um Arbeitszeit zu sparen?"
- Die Softwareentwickler sind mit den schreiben der Tests beschäftigt. Die fachlichen Tests kann der Entwickler nicht durchführen (bzw. wäre ein bisschen grotesk). Somit wird die zuständige Abteilung nicht entlastet.
- Von heute auf morgen passiert sowieso nichts. Jemand muss die Tests erstmal schreiben.

"Um kurzfristig Kosten zu sparen?"
- Nope. Es wird wahrscheinlich sogar noch mehr Personal benötigt oder die Produktivität (neue Features) werden weniger ... die Tests schreiben sich nicht von alleine. Wer schreibt die Tests? ... Stundenlohn externer Softwareentwickler vs. Stundenlohn eigener Mitarbeiter.

"Bei XYZ passiert immer etwas und wir mussten das in diesem Jahr schon 100x testen."
- Eine Stelle, die 80% der Testzeit in Anspruch nimmt ... okey und dazu willst du jetzt 100% des Codes "testbar" gestalten? Vielleicht schreibst du einfach diese Komponente neu und implementierst dort automatisierte Tests.

 

[Airwolf89]

Hallo,

schon mal danke für die Antwort.

Gut, dann versuch ich mal ein wenig Licht ins Dunkle zu bringen.

Erstmal vorneweg, bezahlte Lernzeit beim Kunden, jap, trifft zu. Wir waren uns alle im Klaren darüber wie die Situation ist. Das automatisierte Testen ist auch nur nen Teil meiner Aufgabe dort. Ein Teil war wie gesagt die kleineren Testtools (nettes kleines Tool um ear files zu vergleichen und zu dokumentieren welche Klassen sich geändert haben und welche Methoden die aufrufen und wo die aufgerufen werden) und andere kleine Sachen, nen weiterer Teil ist Prozessoptimierung, da hab ich schon ein wenig Erfahrung gesammelt und da versuchen wir nen netten, kleinen Prozess zu finden um die Abläufe zu optimieren. Der Projektleiter von denen hat scheinbar nur marginalen Einblick in den Entwicklungsprozess wie mir scheint, das sollte man ändern... Aber das nur nebenbei.

Zur Größe der Applikation kann ich nicht viel sagen, ehrlich gesagt weiß ich nicht wie man die Größe von ner Applikation misst^^ Was die LOC angeht, habs nicht gezählt, sollte aber im 6 Stelligen Bereich liegen.
Es ist eine Server Applikation und (natürlich zusätzlich) eine Swing Gui Applikation die mit dem Server kommuniziert.
Hinten dran hängt ne Oracle DB, die Daten kommen per Websphere Message Queue. Die Daten gehen per JDBC in die DB, ob da noch nen Framework dazwischen hängt weiß ich noch nicht. Das Teil läuft auf nem JBoss Server. Die Builds laufen über nen Ant Script.

Es gibt im Unternehmen ein abgeschottetes Test System aber jeder arbeitet mit ner lokalen Installation, ich hab auch eine (alles komplett lokal). Zur Zeit arbeiten 4 Leute dran, die Applikation ist schon einige Jahre alt und wird ständig weiter entwickelt. SVN wird natürlich verwendet. Es gibt einige Branches die sich teilweise sehr unterscheiden (mehrere Versionen für mehrere Kunden) die sollen langfristig zusammengefasst werden. Meine Tools sollen auch Klarheit bringen inwiefern sich die Versionen unterscheiden damit später die Konsolidierung leichter gemacht werden kann. Die automatisierten Tests sollen diesen Prozess unterstützen indem man zentrale Module die überall gleich sind automatisiert testen kann um den sowieso schon hohen Aufwand der Konsolidierung zu verringern. Deswegen den Datenimport (der mithilfe von JMS implementiert ist) als erste Anlaufstelle weil der in allen wohl Versionen weitestgehend gleich ist.

Was die bestehenden Tests angeht, klar, kann mich auch irren, aber für mich sieht es so aus. Veraltet sind sie in jedem Fall, dadurch läuft auch kein einziger. Die Tests greifen auch auf Dateien zu die nirgends mehr existieren. Nicht vollständig auch in der Hinsicht dass die Klassen vollgestopft sind mit TODO Kommentaren (die ich leider noch nicht ganz verstehe) und jede Menge auskommentiertem Code. Wie gesagt, laufen tut kein einziger, aber das sollte hauptsächlich dem Alter zuzuschreiben sein.

Bisher wird halt komplett manuell getestet, nen genaueres Testkonzept und Vorgaben scheints da nicht zu geben, allerdings kommen wohl relativ wenige Bugs vom Kunden zurück, von daher ist die Situation schon mal nicht allzu kritisch. Hauptproblem ist halt der hohe manuelle Aufwand und die Menge der anstehenden Aufgaben. Durch die automatisierten Tests sollen hier vor allem Standardprozesse schneller abgehakt werden können. Die Entwickler machen natürlich nur die technischen Tests, die fachlichen Tests werden zusammen mit dem Kunden gemacht. Allerdings sind die Entwickler auch in der fachlichen Materie fit und wissen auch was da fachlich passiert (Bankenumfeld)

Das der Code überarbeitet werden muss war auch schon im Gespräch. Mein Vorschlag war dass man bei den beteiligten Methoden die bisher voids sind, da wenigstens nen boolean zurück gibt ob die gerade ausgeführte Aktion erfolgreich war, damit könnte man dann zumindest grob die einzelnen Funktionen testen. Allerdings mag ich die Idee auch nicht bestehenden funktionieren Code zu ändern um Tests implementieren zu können. Da allerdings in den letzten Jahren komplett ohne Augenmerk auf automatisierte Tests entwickelt wurde, befürchte ich, kommen wir da nicht drumherum.

Diese Testframeworks werde ich mir mal genauer anschauen, ich hoffe dass die weiteren Infos vielleicht ein wenig Licht in die Sache bringen konnten und ihr noch nen paar Hinweise geben könntet.

Danke im voraus.

 

[Airwolf89]

@ Ruzmanz: Wenn hier alle einhellig der Meinung sind dass man da nachträglich nur sehr schwer oder gar nicht automatisierte Tests zu implementieren sind und man den Weg gehen sollte dass man die Komponenten neu strukturieren und entsprechend auf Unit Tests auslegen muss, dann ist das auch ne Aussage die ich den Leuten da geben kann (solange ich gute Argumente dafür habe)

 

[kama]

Hi,

Erstmal vorneweg, bezahlte Lernzeit beim Kunden, jap, trifft zu. Wir waren uns alle im Klaren darüber wie die Situation ist. Das automatisierte Testen ist auch nur nen Teil meiner Aufgabe dort.

Definitiv ein Punkt für Ehrlichkeit.

Ein Teil war wie gesagt die kleineren Testtools (nettes kleines Tool um ear files zu vergleichen und zu dokumentieren welche Klassen sich geändert haben und welche Methoden die aufrufen und wo die aufgerufen werden)

Wozu hat man eine Versionskontrolle ?
EAR kann man so nur statisch analysieren...da wäre dann eine Laufzeitanalyse sinnvoller im entsprechenden Applikation Server...wenn schon...

Zur Größe der Applikation kann ich nicht viel sagen, ehrlich gesagt weiß ich nicht wie man die Größe von ner Applikation misst^^ Was die LOC angeht, habs nicht gezählt, sollte aber im 6 Stelligen Bereich liegen.
Es ist eine Server Applikation und (natürlich zusätzlich) eine Swing Gui Applikation die mit dem Server kommuniziert.
Hinten dran hängt ne Oracle DB, die Daten kommen per Websphere Message Queue. Die Daten gehen per JDBC in die DB, ob da noch nen Framework dazwischen hängt weiß ich noch nicht. Das Teil läuft auf nem JBoss Server. Die Builds laufen über nen Ant Script.

Hm..6 Stelliger Bereich...

Websphere Message Queue und dann auf einem JBoss Server laufen ? Hört sich komisch an...

Es gibt im Unternehmen ein abgeschottetes Test System aber jeder arbeitet mit ner lokalen Installation, ich hab auch eine (alles komplett lokal). Zur Zeit arbeiten 4 Leute dran, die Applikation ist schon einige Jahre alt und wird ständig weiter entwickelt...

Bei der Menge Code sind 4 leute garnichts...bei der LOC würde ich mal empfehlen da mal ca. 40-60 Leute ranzulassen, damit in absehbarer Zeit was rauskommt...

SVN wird natürlich verwendet. Es gibt einige Branches die sich teilweise sehr unterscheiden (mehrere Versionen für mehrere Kunden) die sollen langfristig zusammengefasst werden. Meine Tools sollen auch Klarheit bringen inwiefern sich die Versionen unterscheiden damit später die Konsolidierung leichter gemacht werden kann.

Mir ist nicht klar warum noch Tools geschrieben werden wenn doch einen Versionskontrolle da ist...die ist genau für den Vergleich da....leichtere Angleichung mit entsprechenden Sync Merges auf die Branches vom trunk damit die Code Unterschiede nicht so groß werden...und die spätere Integration einfacher wird...

Wird denn nach jedem Checkin automatisch gebaut, um wenigstens das zu prüfen ? Ich vermute nein.

Die automatisierten Tests sollen diesen Prozess unterstützen indem man zentrale Module die überall gleich sind automatisiert testen kann um den sowieso schon hohen Aufwand der Konsolidierung zu verringern.

Wenn der Aufwand in der Integration steckt, dann läuft da grundlegends was schief....Branches müssen regelmäßig synchronisiert werden....etc. (Branching Konzept?)

Deswegen den Datenimport (der mithilfe von JMS implementiert ist) als erste Anlaufstelle weil der in allen wohl Versionen weitestgehend gleich ist.

Komisch eben was es nocht XML ?

Was die bestehenden Tests angeht, klar, kann mich auch irren, aber für mich sieht es so aus. Veraltet sind sie in jedem Fall, dadurch läuft auch kein einziger. Die Tests greifen auch auf Dateien zu die nirgends mehr existieren. Nicht vollständig auch in der Hinsicht dass die Klassen vollgestopft sind mit TODO Kommentaren (die ich leider noch nicht ganz verstehe) und jede Menge auskommentiertem Code. Wie gesagt, laufen tut kein einziger, aber das sollte hauptsächlich dem Alter zuzuschreiben sein.

auskommertierter Code zeigt, dass die Nutzung einens Versionskontrollsystems nicht klar ist und dessen Zweck nicht verstanden wurde...

Bisher wird halt komplett manuell getestet, nen genaueres Testkonzept und Vorgaben scheints da nicht zu geben, allerdings kommen wohl relativ wenige Bugs vom Kunden zurück, von daher ist die Situation schon mal nicht allzu kritisch. Hauptproblem ist halt der hohe manuelle Aufwand und die Menge der anstehenden Aufgaben. Durch die automatisierten Tests sollen hier vor allem Standardprozesse schneller abgehakt werden können. Die Entwickler machen natürlich nur die technischen Tests, die fachlichen Tests werden zusammen mit dem Kunden gemacht. Allerdings sind die Entwickler auch in der fachlichen Materie fit und wissen auch was da fachlich passiert (Bankenumfeld)

Oh mann, da braucht man sich ja nicht zu wundern warum Leute so schlecht von Banken denken...

Das der Code überarbeitet werden muss war auch schon im Gespräch. Mein Vorschlag war dass man bei den beteiligten Methoden die bisher voids sind, da wenigstens nen boolean zurück gibt ob die gerade ausgeführte Aktion erfolgreich war, damit könnte man dann zumindest grob die einzelnen Funktionen testen. Allerdings mag ich die Idee auch nicht bestehenden funktionieren Code zu ändern um Tests implementieren zu können. Da allerdings in den letzten Jahren komplett ohne Augenmerk auf automatisierte Tests entwickelt wurde, befürchte ich, kommen wir da nicht drumherum.

Da hat aber bei der Erstellung völlig gepennt und wieder mal leute rangelassen die von Softwareentwicklung absolut keine Ahnung haben...


Hm...
Karl Heinz Marbaise

 

[Airwolf89]

Gut, damit wäre die Situation ja erstmal klar. Dass da einiges nicht so gelaufen ist wie es sollte war ja auch klar, sonst müsste noch mir nicht den Kopf darüber zerbrechen wie man das nachträglich lösen könnte. Dass ich auch nicht der geeignetste für die Aufgabe aufgrund meiner mangelnden Erfahrung bin ist mir auch klar, deswegen Frage ich ja nach Rat . Ändert aber leider an der Situation nichts. Ich hätte halt gerne was was ich denen sagen kann, also, wie würdet ihr mit so ner Situation umgehen, außer das Projekt nochmal von vorn anzufangen, davon wären die glaube ich nicht so begeistert

Was das mit dem import angeht, die MQ kriegt wohl Daten per XML und schiebt das entsprechend weiter an den jms import. Zumindest ist das der manuelle Prozess. Die MQ ist auch nicht direkt teil von der Applikation, sondern wird noch für andere Sachen benutzt und die Applikation hängt da mit dran. So 100%ig weiß ich das auch noch nicht, bin auch noch nicht so lange an dem Thema dran.

 

[Ruzmanz]

@ Ruzmanz: Wenn hier alle einhellig der Meinung sind dass man da nachträglich nur sehr schwer oder gar nicht automatisierte Tests zu implementieren sind und man den Weg gehen sollte dass man die Komponenten neu strukturieren und entsprechend auf Unit Tests auslegen muss, dann ist das auch ne Aussage die ich den Leuten da geben kann (solange ich gute Argumente dafür habe)

So habe ich das nicht gemeint. Dein Kunde hat ein Ziel vor dem Auge. Das Ziel sind nicht automatisierte Tests. Automatisierte Tests sind unter anderem ein Mittel, um dieses Ziel zu erreichen ... Zum Beispiel ist das Ziel die Tests in einem Rutsch (alle Versionen gleichzeitig) zu testen und somit den Testaufwand zu reduzieren.

Was ist das Problem? Mehrere Branches mit unterschiedlichen Code. Die Unterschiede sind unbekannt. Aus diesem Grund ist der manuelle Testaufwand 4x so hoch (bei 4 Versionen), wie er eigentlich sein müsste. Durch eine Testautomatisierung würde der Testaufwand langfristig auf 1/4 sinken. Brauchst du für dieses Ziel wirklich eine Testautomatisierung? Wenn du nun deine Energie in die Zusammenführung der Branches steckst, dann sinkt der Testaufwand auch auf 1/4 (und der Testaufwand bleibt Konstant bei 1). Zudem geht die Entwicklung der Software schneller vorran, ist sicherer (kein Abgleichen, kein Copy&Paste), die Änderung war sowieso geplant und das Projekt für die Testautomatisierung entfällt (Zeit/Kosten sparen).

In diesem speziellen Fall (mit diesem Ziel) wäre somit eine Testautomatisierung reine Zeit-/Geldverschwendung. Sollte es noch andere "Parameter" / Ziele geben, dann müsste man die Geschichte nochmal überdenken ...

Das der Code überarbeitet werden muss war auch schon im Gespräch. Mein Vorschlag war dass man bei den beteiligten Methoden die bisher voids sind, da wenigstens nen boolean zurück gibt ob die gerade ausgeführte Aktion erfolgreich war, damit könnte man dann zumindest grob die einzelnen Funktionen testen. Allerdings mag ich die Idee auch nicht bestehenden funktionieren Code zu ändern um Tests implementieren zu können. Da allerdings in den letzten Jahren komplett ohne Augenmerk auf automatisierte Tests entwickelt wurde, befürchte ich, kommen wir da nicht drumherum.

Code testet man nicht mit Code. Das ist viel zu komplex. Man gibt Daten rein und schaut sich die Ausgabe an.

// CODE

private String xyz = "";

public void setXYZ(String xyz) {
    if(xyz.equals("ABC")) {
        this.xyz = "01";
    } else {
        this.xyz = "00";
    }
}

// TEST
String input = "ABC";
Klasse zuTestendeKlasse = new Klasse();
assertTrue("01", zuTestendeKlasse.getXYZ());

Was dir dein Code nicht verrät ist, dass der Code falsch ist und somit du den Test falsch erstellt hast. Es müsste eigentlich 'assertTrue("02", zuTestendeKlasse.getXYZ());' lauten. So würde das in der Dokumentation stehen, die es wahrscheinlich nicht gibt Soll dir ein bisschen zum Denken geben ... ein "return true" bei setXYZ() sagt ebenso wenig aus. Aus diesem Grund prüfst du i.d.R. den die "Daten" des Outputs.