Fernuniversität in Hagen. Untersuchungen zum Selbsttest von JUnit

Transkript

1 Fernuniversität in Hagen FACHBEREICH INFORMATIK LEHRGEBIET PROGRAMMIERSYSTEME Prof. Dr. Friedrich Steimann Untersuchungen zum Selbsttest von JUnit Abschlussarbeit im Studiengang Informatik Abschluss Bachelor of Science Vorgelegt von Sabrina Fömpe Matrikelnummer Betreut durch Marcus Frenkel Köln, November 2012

2

3 Zusammenfassung Diese Bachelor-Arbeit befasst sich mit der Verwendung von JUnit als Testprojekt für EzUnit. Da JUnit ein integraler Bestandteil des EzUnit Frameworks ist, wird hier von Untersuchungen zum Selbsttest von JUnit gesprochen. Durch die enge Zusammenarbeit der beiden Frameworks kommt es bei der Konstellation von JUnit als Testprojekt von EzUnit zu erheblichen Problemen. Diese Probleme werden in der vorliegenden Arbeit genau beschrieben und ein Lösungsansatz vorgeschlagen und evaluiert, mit dem eine solche Testkonstellation dennoch durchführbar ist. Schlüsselwörter: EzUnit, JUnit

4

5 Glossar EzJIP Anpassung von JIP für EzUnit IDE Integrated Development Environment JDT Java Development Tools JIP Java Interactive Profilers JUnit 3 JUnit Projekt in der Version JUnit 4 JUnit Projekt in der Version 4.10 JUnit 3 4 ohne Fehler entspricht dem jeweiligen JUnit 3 4 Projekt JUnit 3 4 mit injizierten Fehlern fasst die beiden Testprojekte allgemeiner Fehlerfall JUnit 3 4 und Spezialfall Assert JUnit 3 4 zusammen (zu den Unterschieden der beiden fehlerinjizierten Versionen siehe Abschnitt 3.1.2, S. 20) MUT Method Under Test PDE Plug-in Development Environment RefUnit 3 JUnit 3 Projekt nach Refactoring RefUnit 4 JUnit 4 Projekt nach Refactoring RefUnit 3 4 ohne Fehler entspricht dem jeweiligen RefUnit 3 4 Projekt RefUnit 3 4 mit injizierten Fehlern entspricht den JUnit 3 4 Projekten mit injizierten Fehlern nach Refactoring

6

7 Inhaltsverzeichnis 1 Einleitung 1 2 Grundlagen Testautomatisierung Eclipse JUnit JUnit JUnit EzUnit Die EzUnit Benutzeroberfläche JUnit als Testprojekt Problemerfassung Vorgehen Referenztestfälle Fehler-Injizierung Logausgaben Analyse Testprojekt JUnit 3 ohne Fehler Testprojekt JUnit 4 ohne Fehler Testprojekt JUnit 3 mit injizierten Fehlern Testprojekt JUnit 4 mit injizierten Fehlern Auswertung der Analyseergebnisse Umsetzung Vorgehen Refactoring der Paket-Struktur Refactoring der Paketnamen Ergebnisse Testprojekt RefUnit 3 ohne Fehler Testprojekt RefUnit 4 ohne Fehler Testprojekt RefUnit 3 mit injizierten Fehlern Testprojekt RefUnit 4 mit injizierten Fehlern Evaluierung Grundlagen AspectJ Implementierung Taspect EzUnitComparator Auswertung Testprojekte RefUnit Testprojekte RefUnit

8 5.3.3 Fazit Zusammenfassung 60 Literatur 65 A Anhang 67 B Inhalt der beiliegenden CD 82 C Erklärung 83

9 1 Einleitung JUnit ist eines der bekanntesten Frameworks zum Unit-Testen in Java [Ste05]. Es ist frei verfügbar und hat seine Popularität nicht zuletzt seinen Autoren Kent Beck und Erich Gamma zu verdanken, die mit JUnit das einfache Testen von Java-Programmen ermöglicht haben. JUnit selbst ist in Java implementiert und unter anderem direkt in Eclipse integriert. Beim Unit-Testen werden Module eines zugrunde liegenden Programms auf ihre Korrektheit überprüft. JUnit unterstützt den Entwickler dabei Unit-Tests durchzuführen, indem es die Möglichkeit bietet, Testfälle zu schreiben und diese als Regressionstests immer wieder ausführen zu können. Als Ergebnis zeigt JUnit an, welche Testfälle fehlerfrei gelaufen sind und welche Testfälle mit einem Fehler beendet wurden [TLMG11]. Über die fehlerhafte Stelle im Quellcode des zugrunde liegenden Testprojektes gibt JUnit jedoch keine Auskunft. Um die potentiell fehlerhaften Stellen im Quelltext von Java-Programmen zu lokalisieren, ähnlich wie es bei der Verwendung von Compilern der Fall ist, wurde an der Fernuniversität in Hagen im Lehrgebiet Programmiersysteme ein Framework entwickelt, welches JUnit um genau diese Funktionalität erweitert [SEES08]. Es handelt sich dabei um das EzUnit Framework, welches als Eclipse Plug-in implementiert ist. Es setzt auf dem JUnit Framework auf, indem es einen eigenen Test Run Listener [Mey07] zum Mithören von JUnit Testläufen implementiert und darüber hinaus den Ablauf von JUnit Tests mittels einer Erweiterung des Java Interactive Profilers (JIP) [Ber10] analysiert (im Folgenden als Tracing bezeichnet). Beim Tracing werden alle Methoden ermittelt, die beim Ausführen von JUnit Tests aufgerufen werden. Dazu gehören neben den Methoden des Testprojektes auch Methoden, die vom Framework selbst zur Testausführung und -auswertung benötigt werden. Um nur die Methoden zu erhalten, die sich im Quelltext des zugrunde liegenden Testprojektes befinden, werden alle Methoden gefiltert, die für die Testausführung selbst benötigt werden. Die Methoden des Testprojektes werden als MUTs (Methods Under Test) bezeichnet. Sie werden mit Hilfe von konfigurierbaren Fehlerlokatoren analysiert, um ihren Verdächtigkeitswert zu ermitteln. Dieser Wert sagt aus, wie wahrscheinlich es ist, dass eine Methode für das Scheitern eines Testfalls verantwortlich ist [Ber10]. Da JUnit und EzUnit stark miteinander verwoben sind, kann man bei der Verwendung von JUnit als Testprojekt für EzUnit von einem JUnit Selbsttest sprechen. Die enge Zusammenarbeit der beiden Frameworks verursacht bei einem solchen Selbttest nicht unerhebliche Probleme. Beim Filtern der durch das Tracing ermittelten Methoden kann bei einem JUnit Selbsttest keine Unterscheidung zwischen Testframework und zugrunde liegendem Testprojekt mehr getroffen werden. 1

10 Diese Bachelorarbeit befasst sich mit der Untersuchung von JUnit als Testprojekt für EzUnit und beschreibt die dabei entstehenden Probleme. Die Arbeit ist wie folgt aufgebaut: In Abschnitt 2 werden die Grundlagen zum Verständnis dieser Arbeit beschrieben, die beiden Frameworks EzUnit (Abschnitt 2.4) und JUnit (Abschnitt 2.3) im Einzelnen vorgestellt und ihre Zusammenarbeit im Detail erläutert. Abschnitt 3 befasst sich mit der genauen Analyse der auftretenden Probleme bei der Verwendung von JUnit als Testprojekt für EzUnit. In Abschnitt 4 wird ein Lösungsansatz vorgeschlagen, der den Selbsttest von JUnit mittels Refactoring ermöglichen soll. Die Ergebnisse der Umsetzung werden im Detail betrachtet und in Abschnitt 5 wird eine ausführliche Evaluierung durchgeführt, um die Güte des Lösungsansatzes zu prüfen. Abschnitt 6 fasst die wesentlichen Erkenntnisse dieser Arbeit noch einmal kurz zusammen. 2

11 2 Grundlagen Der fachliche Rahmen, in dem sich diese Arbeit bewegt, soll durch einen kurzen Einblick in die Testautomatisierung und insbesondere das Unit-Testen gegeben werden. Desweiteren werden die beiden Frameworks JUnit und EzUnit im Detail vorgestellt und ihre Zusammenarbeit erläutert. Da beide Frameworks als Eclipse Plug-ins verfügbar sind, soll vorab ein kurzer Abriss über Eclipse selbst gegeben werden. 2.1 Testautomatisierung Um die Qualität von Software sicher zu stellen, ist die Testautomatisierung ein wichtiges Werkzeug geworden [TLMG11]. Sie ermöglicht eine erhebliche Zeitersparnis gegenüber dem manuellen Testen. Einmal erstellt, können die Testfälle immer wieder auf dem Testprojekt durchgeführt werden. Man spricht hierbei von sogenannten Regressionstests [Bal98], die dazu dienen, die korrekte Funktion von Programmen nach Änderungen sicherzustellen. Da das frühzeitige Aufdecken von Fehlern in Software eine erhebliche Kostenersparnis mit sich bringt [Bec09], sind insbesondere auch Testautomatisierungswerkzeuge von großem Interesse, die sich bereits im Entwicklungszyklus einsetzen lassen. In genau diesem Rahmen bewegen sich die beiden hier vorgestellen Frameworks JUnit und EzUnit. Sie ermöglichen das sogenannte Unit-Testen, bei dem einzelne Programmiereinheiten daraufhin überprüft werden, ob sie zu gegebenen Eingaben die erwarteten Ausgaben liefern [Ste05]. Um eine möglichst hohe Testabdeckung zu erzielen, sollte für jede Programmeinheit mindestens ein Testfall erzeugt werden. Daraus ergibt sich eine 1:n-Beziehung von Einheiten zu Testfällen. In der Praxis ergibt sich jedoch häufig eine m:n-beziehung, da durch Methodenaufrufe im Testprojekt häufig mehrere Einheiten von einem Testfall abgedeckt werden. Dies erschwert die Fehlersuche im Quelltext des Testprojektes. 2.2 Eclipse Eclipse ist eine universelle Plattform, die es ermöglicht, Werkzeuge in Form von sogenannten Plug-ins einzubinden und auszuführen. Obwohl Eclipse selbst in Java implementiert wurde, ist es sprach-neutral [Hol09]. 3

12 Abbildung 1: Aufbau der Eclipse Architektur nach [Hol09] Neben einigen grundsätzlichen Komponenten wie z.b. dem Kernel, der die Ausführung der Plug-ins ermöglicht, wird Eclipse mit der Java-IDE (IDE steht für Integrated Development Environment) Java Development Tools (JDT) ausgeliefert, welche die Entwicklung von Java-Programmen unterstützt. Ebenfalls ein integraler Bestandteil der Plattform ist das sogenannte Plug-in Development Environment (PDE) (vgl. Abbildung 1). Es ermöglicht das Entwickeln von eigenen Eclipse Plug-ins. 2.3 JUnit JUnit ist eines der meistverbreiteten Frameworks für das Erstellen von automatisierten Unit-Tests im Java-Umfeld. Es ist ein integraler Bestandteil des Eclipse JDT und ermöglicht das Testen von Java-Projekten direkt aus der IDE heraus [Hol09]. Wie in [Ste05] beschrieben, besteht ein Testfall in JUnit aus genau einer Testmethode. Jeder Testfall kann vom JUnit Framework einzeln ausgeführt und ausgewertet werden. Intern geht JUnit dabei wie folgt vor: Obwohl eine Testklasse mehrere Testfälle enthalten kann, wird für jeden Testfall eine eigene Instanz der Klasse erzeugt. Die Zuordnung erfolgt über den Namen der Testmethode. Der Aufruf der Testmethoden über ihren Namen erfolgt mittels Reflection [Bec09]. Testklassen können zur gemeinsamen Ausführung zusammengefasst werden. Hierfür bietet JUnit die Möglichkeit sogenannte Testsuites zu erstellen. Eine Testsuite kann dazu genutzt werden, mehrere Testklassen (oder auch Testsuites) gemeinsam auszuführen. Der einzelne Testfall sollte vom Entwickler jedoch so gestaltet werden, dass er unabhängig von anderen Testfällen ausgeführt werden kann. Er sollte darüber hinaus fehlerfrei durchlaufen, wenn zu den gegebenen Eingaben die erwarteten Ergebnisse geliefert werden [TLMG11]. Hierfür bietet das JUnit Framework verschiedene Methoden an, mit denen erwartete und tatsächlich vorgefundene Ergebnisse verglichen werden können. Hier sind zum Beispiel die Methoden der Klasse Assert zu nennen. Diese liefern für einen nicht zutreffenden Vergleich einen entsprechenden Fehler (AssertionFailedError), der vom JUnit Framework ausgewertet wird. Testmethoden, die mit einem erwarteten Ergebnis 4

13 beendet wurden, werden als erfolgreich ausgeführt angesehen; Testmethoden, die mit einem unerwarteten Ergebnis beendet wurden, werden von JUnit als fehlerhaft ausgezeichnet [Ste05]. Das JUnit Framework unterscheidet zwei Arten von Fehlern, sogenannte Errors und sogenannte Failures. Failures indizieren ein Testergebnis, welches nicht den definierten Erwartungen entspricht. Sie werden von einem AssertionFailedError ausgelöst. Errors dagegen werden von Laufzeitfehlern ausgelöst, sofern diese nicht erwartet werden. Eine gesonderte Fehlerbehandlung durch den Entwickler ist in JUnit Testfällen somit nicht erforderlich. Gesammelt werden die Ergebnisse und Informationen zu einem ausgeführten Testlauf (das bedeutet zu allen zusammen ausgeführten Testklassen und Testsuites) von einer Instanz der Klasse TestResult [Ste05]. JUnit bietet die Möglichkeit, Vor- und Nacharbeiten für die Ausführung einer oder mehrerer Testmethoden zu definieren, die sogenannte Test Fixture. Mithilfe dieser Test Fixture können z.b. für die Testausführung benötigte Ressourcen initialisiert und nach der Ausführung eines Testfalls wieder gelöscht werden. Durch den Einsatz von Test Fixtures können Abhängigkeiten zu anderen Testmethoden vermieden werden [TLMG11]. Auch für die Reproduzierbarkeit von immer gleichen Ausgangssituationen, gerade unter dem Aspekt der Revisionstests, ist diese Möglichkeit der Testaufbereitung sehr nützlich. Eine Test Fixture, die in einer Testklasse definiert wurde, ist für alle Instanzen dieser Klasse gültig und muss nicht für jede Testmethode implementiert werden. Es ist daher sinnvoll, Testmethoden, die eine gleiche Test Fixture benötigen, in einer Testklasse zusammenzufassen [Ste05]. Aus Eclipse heraus lassen sich Testsuites, Testfälle oder Testmethoden unter anderem über das angebotene Kontextmenü erzeugen und ausführen. Wichtig ist, dass JUnit in den Klassenpfad des Test-Projektes eingebunden ist. Nach dem Durchlauf der oder des Tests wird das Ergebnis des Testlaufs von JUnit im sogenannten JUnit View angezeigt (siehe Abbildung 2). Dort werden sowohl die Anzahl der ausgeführten Testmethoden (als Runs bezeichnet) als auch die Anzahl der Failures und Errors dokumentiert. Die Tests sind hierarchisch in einer Baumstruktur dargestellt. Die Ergebnisse werden von den Testmethoden aus an die umfassenden Testklassen und Testsuites propagiert. Eine Testklasse, die mindestens eine fehlerhafte Testmethode enthält, wird ebenfalls als fehlerhaft markiert, gleiches gilt für eine Testsuite. Es gibt noch eine erweitere Ansicht des JUnit Views, den sogenannten Failure Trace View, der Hinweise auf einen aufgetretenen Fehler gibt. Dabei wird für jede fehlerhafte Testmethode ein entsprechender Stacktrace angegeben, der auf die Stelle im Testfall verweist, an der der Fehler aufgetreten ist [Bec09]. 5

14 Abbildung 2: Exemplarisches Testergebnis von JUnit Abbildung 2 zeigt das Testergebnis für eine Testklasse SimpleIntCalculatorTest, die sechs Testmethoden enthält. Die Anzahl der festgestellten Errors (rot markiert) beträgt eins und es werden zwei Failures (schwarz markiert) angezeigt. Für die beiden Testfälle testsubstract() und testaddandsubstract() ist je ein AssertionFailedError aufgetreten. Dieser wird im Failure Trace View zu Testmethode testsubstract() angezeigt. Der zugehörige Stacktrace identifiziert den aufgetretenen Fehler und gibt sowohl das erwartete, als auch das tatsächliche Ergebnis aus. Der Testfall testdividebyzero() wurde mit einem Error beendet. Hier wurde bei der Testausführung ein Laufzeitfehler ausgelöst. Der Testfall SimpleIntCalculatorTest wird in Folge dessen ebenfalls als fehlerhaft markiert (in diesem Fall rot, da ein Error aufgetreten ist). JUnit ist in mehreren Versionen erhältlich. Für diese Arbeit werden exemplarisch zwei Versionen des Projektes betrachtet. Zum einen die Version als Vertreterin von JUnit in der Version 3 (im Folgenden als JUnit 3 bezeichnet) und zum anderen die Version 4.10 als Vertreterin von JUnit in der Version 4 (im Folgenden als JUnit 4 bezeichnet). Bei beiden Versionen handelt es sich um die jeweils aktuellsten stabilen Vertreter zum Zeitpunkt der Erstellung dieser Arbeit. In den nächsten beiden Abschnitten werden beide 6

15 Versionen kurz vorgestellt. Der Funktionsumfang beschränkt sich dabei auf die für das Verständnis dieser Arbeit wesentlichen Teile. Für nähere Informationen sei auf die den Abschnitten und zu Grunde liegende Literatur verwiesen [Bec09, TLMG11] JUnit 3 Der Quelltext des JUnit 3 Projektes ist in der folgenden Paket-Struktur organisiert, siehe Abbildung 3. Abbildung 3: Paket-Struktur von JUnit 3 Die Links zum Quelltext und den zugehörigen Testfällen des Projektes sind im Literaturverzeichnis aufgeführt [JU3S, JU3T]. Um eine Testklasse in JUnit 3 zu erstellen, muss diese eine Subklasse von junit. framework.testcase sein. Alle Testmethoden müssen mit dem Namenspräfix test beginnen und mit dem Modifier public deklariert sein, um als Testfälle erkannt zu werden. Testmethoden dürfen darüber hinaus keine Parameter oder Rückgabewerte haben. Die Test Fixture kann durch das Überschreiben der Methoden setup() und teardown() in der Testklasse hinzugefügt werden [Bec09]. Um eine Testsuite zu erzeugen, muss diese die Klasse junit.framework.testsuite erweitern. Eine Testsuite ist dabei selbst, genau wie eine Testklasse, von JUnit ausführbar. Beide implementieren das Interface junit.framework.test. Eine wichtige Klasse des Frameworks, die an dieser Stelle vorgestellt werden soll, ist die Klasse junit.framework.assert. Sie bietet einige Methoden an, die für die Verifizierung von Ergebnissen eines Testfalls benutzt werden können. Das ermöglicht dem Entwickler, JUnit seine Erwartungen an das Testergebnis mitzuteilen und von JUnit überprüfen zu lassen. Exemplarisch sei hier die Methode asserttrue(boolean condition) vorgestellt, die einen booleschen Wert entgegennimmt und diesen auswertet. Sollte der Wert nicht wie erwartet true sein, wird ein junit.framework.assertionfailederror erzeugt, der von JUnit zu einem Failure ausgewertet wird. 7

16 Listing 1 illustriert den Aufbau einer JUnit 3 Testklasse. Es handelt sich dabei um einen Auszug der Testklasse, die für das Testergebnis aus Abbildung 2 (S. 6) verwendet wurde. 1 public class S i m p l e I n t C a l c u l a t o r T e s t extends TestCase { 2 3 private static S i m p l e I n t C a l c u l a t o r c a l c u l a t o r = null ; 4 5 public void setup ( ) { 6 c a l c u l a t o r = new S i m p l e I n t C a l c u l a t o r ( ) ; 7 } 8 9 public void testadd ( ) { 10 a s s e r t E q u a l s ( 3, c a l c u l a t o r. add ( 1, 2) ) ; 11 } public void t e s t S u b s t r a c t ( ) { 14 a s s e r t E q u a l s ( 3, c a l c u l a t o r. s u b s t r a c t ( 4, 1) ) ; 15 } public void testdividebyzero ( ) { 18 a s s e r t E q u a l s ( 1, c a l c u l a t o r. d i v i d e ( 1, 0) ) ; 19 } } Listing 1: Auszug Beispiel Testfall in JUnit 3 Die Testklasse SimpleIntCalculatorTest ist eine Subklasse von junit.framework. TestCase. Die Testmethoden testadd(), testsubstract() und testdividebyzero() tragen jeweils das Präfix test und sind mit dem Modifier public deklariert. Somit können sie vom Framework als Testmethoden erkannt und ausgeführt werden. In den Testmethoden wird ein erwartetes Ergebnis vom Typ int angegeben und von der Methode assertequals(..) mit dem Rückgabewert der Methode add(..), substract(..) bzw. divide(..) der Klasse SimpleIntCalculator verglichen. In Abbildung 2 (S. 6) ist ersichtlich, dass der von SimpleIntCalculator.add(..) zurückgegebene Wert mit dem erwarteten Ergebnis übereinstimmt, und die Testmethode testadd() somit als erfolgreich ausgeführt gekennzeichnet wird. Anders verhält es sich bei der Ausführung der Testmethode testsubstract(). Diese erwartet einen anderen Wert als den der von der fehlerhaft implementierten Methode SimpleIntCalculator.substract(..) zurückgegeben wird. Die Folge ist, dass die Methode assertequals(..) einen junit.framework. AssertionFailedError auslöst. Dieser wird vom JUnit Framework aufgefangen und zu einem Failure ausgewertet. Die Testmethode testdividebyzero() löst einen Laufzeitfehler aus, da bei der Ausführung von SimpleIntCalculator.divide(..) eine java. lang.arithmeticexception auftritt, bei dem Versuch eins durch null zu teilen. 8

17 Das JUnit Framework behandelt diesen Fehler und wertet ihn zu einem Error aus. Das Testprogramm und die zugehörigen Testfälle befinden sich auf der beiliegenden CD (siehe Anhang B, S. 82) JUnit 4 Der Quelltext des JUnit 4 Projektes ist in der folgenden Paket-Struktur organisiert, siehe Abbildung 4. Abbildung 4: Paket-Struktur von JUnit 4 Die Links zum Quelltext und den zugehörigen Testfällen sind im Literaturverzeichnis aufgeführt [JU4]. Gegenüber JUnit 3 bietet JUnit 4 einen wesentlich größeren Funktionsumfang an. Die Paket-Struktur von JUnit 3 (vgl. Abbildung 3) ist um das Paket org.junit erweitert worden. Ein wesentlicher Unterschied zwischen JUnit 3 und JUnit 4 ist, dass JUnit 4 einige Neuerungen unterstützt, die mit Java 5 eingeführt wurden [TLMG11]. Dazu zählen neben der Verwendung von Annotationen auch die Unterstützung von Generics und statischen Imports. Für nähere Informationen zu den Java Sprachkonstrukten sei auf die weiterführende Literatur verwiesen [Ull11]. Durch die Verwendung der neuen Java Sprachkonstrukte hat sich die Art und Weise, wie Testfälle in JUnit 4 erstellt werden, grundsätzlich verändert. In JUnit 4 ist es nicht länger erforderlich, dass eine Testklasse von der Klasse junit.framework.testcase erbt. Die Testmethoden müssen lediglich mit der aus dem Paket org.junit versehen werden. Das gleiche gilt für die Verwendung der Test Fixtures. 9

18 Hierfür gibt es unter anderem die aus dem Paket org.junit [TLMG11]. Annotationen bieten die Möglichkeit, Sprachkonstrukten, wie Klassen oder Methoden, Metainformationen mitzugeben, die z.b. zur Laufzeit ausgelesen werden können [Ste05]. Das macht sich auch das JUnit Framework zunutze, indem es für jede annotierte Testmethode eine entsprechende Instanz erstellt (vgl. Abschnitt 2.3, S. 4). Durch die Verwendung von Annotationen entfallen auch die in JUnit 3 verwendeten Namenskonventionen für Testmethoden. Sie müssen nicht das Namenspräfix test tragen, sondern es ist ausreichend, dass eine entsprechend gekennzeichnete Testmethode mit dem Modifier public deklariert ist und weder Parameter noch Rückgabewerte besitzt [TLMG11]. JUnit 4 ist abwärtskompatibel. Alle JUnit 3 Testfälle lassen sich weiterhin ausführen und natürlich auch erstellen. JUnit 4 arbeitet ebenfalls mit der Unterscheidung von Failures und Errors und das Ergebnis eines JUnit 4 Testlaufs ist äquivalent zu dem in Abbildung 2 (S. 6) gezeigten. Der Auszug der zugehörige Testklasse, die im vorigen Abschnitt in Listing 1 (S. 8) illustriert wurde, könnte mit JUnit 4 wie folgt implementiert werden. 1 import static org. j u n i t. Assert. a s s e r t E q u a l s ; 2 3 public class S i m p l e I n t C a l c u l a t o r T e s t { 4 5 private static S i m p l e I n t C a l c u l a t o r c a l c u l a t o r = null ; 6 8 public void before ( ) throws Exception { 9 c a l c u l a t o r = new S i m p l e I n t C a l c u l a t o r ( ) ; 10 } public void add ( ) { 14 a s s e r t E q u a l s ( 3, c a l c u l a t o r. add ( 1, 2) ) ; 15 } public void s u b s t r a c t ( ) { 19 a s s e r t E q u a l s ( 3, c a l c u l a t o r. s u b t s r a c t ( 4, 1) ) ; 20 } public void dividebyzero ( ) { 24 a s s e r t E q u a l s ( 1, c a l c u l a t o r. d i v i d e ( 1, 0) ) ; 25 } } Listing 2: Auszug Beispiel Testfall in JUnit 4 10

19 Listing 2 zeigt, dass die Testklasse SimpleIntCalculatorTest nicht länger ein Subtyp der Klasse TestCase ist. Stattdessen wurden die enthaltenen Testmethoden add(), substract() und dividebyzero() mit der versehen. JUnit 4 stellt eine eigene Klasse Assert im Paket org.junit zur Verfügung, die genau wie die Klasse junit.framework.assert verschiedene Methoden für die Auswertung von erwarteten und tatsächlichen Ergebnissen zur Verfügung stellt. Die Methoden der Klasse org.junit.assert können über einen statischen Import in die Testklasse eingebunden werden, so dass die Assert Methoden wie in JUnit 3 verwendet werden können. Die org. junit.assert Methoden lösen einen java.lang.assertionerror aus und nicht, wie die junit.framework.assert Methoden, einen junit.framework.assertionfailederror. Die Klasse java.lang.assertionerror wurde mit Java 1.4 eingeführt und in JUnit übernommen. JUnit intern wird ein AssertionError wie ein AssertionFailedError behandelt und zu einem Failure ausgewertet [TLMG11]. Neben der eben beschriebenen Einführung von Annotationen für die Kennzeichnung von Testmethoden und Test Fixtures, gibt es noch einige weitere neue Sprachkonstrukte, die mit JUnit 4 eingeführt wurden. Einige, die für das Verständnis dieser Arbeit relevant sind, sollen im folgenden kurz vorgestellt können Testfälle annotiert werden, die bei der Testausführung nicht berücksichtigt, also ignoriert, werden sollen. Parametrisierte Tests Ein weitere Neuerung in JUnit 4 stellt die Möglichkeit dar, parametriesierte Tests zu erstellen. Dieses Sprachkonstrukt ermöglicht es, einen Testfall mit verschiedenen Ausprägungen zu erzeugen. Die Testklasse muss mit der 1 versehen sein. Die Parameter für die verschiedenen Testausprägungen werden über den Konstruktor der Testklasse angenommen und so den Instanzvariablen der Testklasse zugewiesen. Hierfür wird eine Methode mit der public static java.util.collection erwartet, die eine Collection mit Arrays vom Typ Object zurückgibt. Diese Methode gibt die Datenausprägungen für die parametrisierte Ausführung der Testmethode zurück. Für jede Datenausprägung wird eine Collection zurückgegeben mit einer entsprechenden Anzahl Arrays pro Instanzvariable. Zur Veranschaulichung dient das in Abbildung 11 (S. 79) dargestellte Beispiel. Für einen parametrisierten Testfall zählt JUnit pro Datenausprägung einen Testfall zur Anzahl der Runs hinzu. Wurde ein Testfall mit zwei Datenausprägungen ausgeführt, so zeigt JUnit zwei Runs als Testergebnis. Hamcrest JUnit 4 unterstützt die Bibliothek Hamcrest, mit deren Hilfe es möglich ist, die Assert Methoden von JUnit mit Hilfe von sogenannten Matcher-Objekten nachzubilden. Das erlaubt eine komfortablere und flexiblere Nutzung von Assertions. Für mehr Informationen zu Hamcrest sei an dieser Stelle auf die Projektseite verwiesen [Ham]. 1 Mit der lässt sich ein bestimmter Test Runner zur Testausführung angeben. Für mehr Informationen siehe [TLMG11] 11

20 Theorien In JUnit 4 ist es möglich generische Testfälle, sogenannte Theorien, zu schreiben. Die Testmethode selbst ist dabei mit der zu versehen und die zugehörige Testklasse mit der 2. Die Testklasse muss Felder bereitstellen, die mit public static deklariert sind und die haben. Diese Datenpunkte werden dann als Parameter der Testmethode verwendet. Dabei wird die Testmethode mit allen möglichen sich ergebenden Kombinationen der Datenpunkte ausgeführt [Ste05]. Ein Beispiel zur Veranschaulichung zeigt Abbildung 12, S. 80. Wichtig ist hier zu erwähnen, dass eine Theorie von JUnit immer nur als eine Testmethode gezählt wird, egal wie viele Datenkombinationen ausgeführt werden. 2.4 EzUnit EzUnit ist ein Framework, welches zur Fehlerlokalisierung in Java-Programmen entwickelt wurde. Es ist in Form eines Eclipse Plug-ins gestaltet und entsprechend in Java implementiert. Mit Hilfe von EzUnit lassen sich Testdurchläufe initiieren, deren Ergebnis nicht nur anzeigt, ob ein Testfall fehlerhaft ist oder nicht, sondern auch wo im getesteten Quelltext sich der Fehler voraussichtlich befindet. EzUnit bietet dabei nicht nur Unterstützung für die Lokalisierung eines einzelnen Fehlers, sondern kann auch multiple Fehler lokalisieren [Ber10]. Technisch setzt EzUnit auf dem JUnit Framework auf. Entsprechend können alle JUnit Tests als EzUnit Tests ausgeführt werden. Wird ein EzUnit Testlauf gestartet, so wird zunächst immer ein JUnit Testlauf initiiert. EzUnit implementiert einen sogenannten Test Run Listener, um über den Ablauf und das Ergebnis eines JUnit Testlaufs informiert zu werden. Der Test Run Listener wird in Eclipse als Erweiterungspunkt für Plug-ins angeboten [Mey07]. Um Fehler im Quelltext lokalisieren zu können, benötigt EzUnit neben den allgemeinen Informationen über den Testausgang von JUnit noch die Information, welche Stellen im Quelltext durch die JUnit Tests aufgerufen wurden. Diese Ablaufverfolgung wird als Tracing bezeichnet. Hierfür wurde das Java Interactive Profiler Projekt [JIP] entsprechend erweitert und für die Bedürfnisse von EzUnit angepasst (vgl. EzJIP [Ber10]). Die so gewonnen Tracing-Informationen werden an den sogenannten EzServer übermittelt, der diese entsprechend aufbereitet und auswertet. In EzUnit bilden die Methoden des Testprojektes die kleinste Einheit an testbarem Code, sie werden als MUTs (Methods Under Test) bezeichnet. Weiterhin unterscheidet EzUnit CUTs (Classes Under Test) und PUTs (Packages Under Test). Die vorliegende Arbeit konzentriert sich im Folgenden auf die Betrachtung von MUTs als kleinster Einheit. Auf den beim Tracing ermittelten MUTs wird mit Hilfe von sogenannten Fehlerlokatoren 2 Mit der lässt sich ein bestimmter Test Runner zur Testausführung angeben. Für mehr Informationen siehe [TLMG11] 12

21 eine Berechnung durchgeführt, deren Ergebnis die Information liefert mit welcher Wahrscheinlichkeit die untersuchte Methode fehlerhaft ist. Diese Wahrscheinlichkeit wird als Verdächtigkeitswert bezeichnet [Ber10]. EzUnit bietet die Möglichkeit, mehrere solcher Fehlerlokatoren zu benutzen. Diese können über eine entsprechend bereitgestellte Schnittstelle zum Framework hinzugefügt werden. Die verfügbaren Fehlerlokatoren basieren auf unterschiedlichen Algorithmen und liefern jeweils einen eigenen Verdächtigkeitswert. Welche der verfügbaren Fehlerlokatoren für einen EzUnit Testlauf benutzt werden sollen, ist über die Benutzeroberfläche konfigurierbar. EzUnit berechnet schließlich noch ein globales Ergebnis, das sich aus den verschiedenen errechneten Verdächtigkeitswerten und einer vom Benutzer einstellbaren Gewichtung zusammensetzt [SF10, Ber10]. Als Basis für die Berechnung einiger Fehlerlokatoren dient eine Matrix, die sich aus den durchgelaufenen Testfällen einerseits und aus den aufgerufenen MUTs andererseits zusammensetzt. Es handelt sich dabei um die sogenannte Test Coverage Matrix (TCM). Der Aufbau einer solchen Matrix wird in Tabelle 1 illustriert. Tabelle 1: Aufbau einer Test Coverage Matrix (TCM) nach [SF10] Testmethoden MUTs fehlerhaft fehlerfrei t 1... t m t m+1... t a m 1 x 1,1... x 1,m x 1,m+1... x 1,a m n x n,1... x n,m x n,m+1... x n,a Für jede MUT (m i ) wird angegeben, ob diese durch eine Testmethode (t i ) aufgerufen wird (x i,i =1) oder nicht (x i,i =0). Dabei werden sowohl die fehlerhaften Testfälle (linke Hälfte der Matrix) als auch die fehlerfreien Testfälle (rechte Hälfte der Matrix) berücksichtigt. Um eine TCM aufbauen zu können, werden die durch das Tracing ermittelten Methodenaufrufe durchsucht. Da EzJIP neben den Aufrufen der MUTs auch die Methoden aufzeichnet, die von JUnit zur Testausführung benötigt werden, werden die Tracing- Informationen durch entsprechende Filter bereinigt. Zu den standardmäßig herausgefilterten Methoden gehören die Methoden der Pakete org.junit, junit.framework und org.eclipse. Darüber hinaus bleiben Methoden unberücksichtigt, die in einem Paket liegen, welches für Testfälle vorgesehen ist. Werden diese Filter zurückgesetzt, ergeben sich falsche Verdächtigkeitswerte, da die Matrix durch zusätzliche Einträge (nämlich durch aufgerufene Methoden, die nicht zum Quelltext des Testprojektes gehören) verfälscht wird. Werden in den ausgeführten Testmethoden beispielsweise Assert Methoden 13

22 zur Überprüfung von Ergebnissen eingesetzt, so würde EzUnit nicht erkennen, dass der Aufruf der Assert Methode nicht Teil des zugrunde liegenden Testprojektes ist, sondern dass es sich dabei um eine Methode des Testframeworks handelt. Die Assert Methode würde somit fälschlicherweise als MUT erkannt werden, was durch die Filtereinstellungen verhindert wird. Die Filterfunktionen von EzUnit können über einen Dialog eingestellt werden, der über die Eclipse Oberfläche aufgerufen werden kann (Menüeintrag Window Preferences EzUnit Filter). Der Dialog ist in Abbildung 5 dargestellt und wird im Folgenden kurz erläutert. Abbildung 5: Filtereinstellungen von EzUnit Unter dem Eintrag Exclude Packages können Pakete eingetragen werden, die bei der MUT-Ermittlung durch EzUnit nicht mit berücksichtigt werden sollen (beispielsweise junit.framework um die Assert Methoden auszuschließen). Unter dem Eintrag Included Packages können gezielt Pakete angegeben werden, die explizit für die MUT Ermittlung freigeben sind. So können ggf. Pakete aus Exclude Packages überschrieben werden. 14

23 Unter dem Eintrag Exclude Source Folders können Pakete angegeben werden, in denen sich Testfälle befinden. So kann beispielsweise verhindert werden, dass Test Fixtures als MUTs berücksichtigt werden [EzU5]. Wie bereits erwähnt, kann EzUnit nicht nur einen einzelnen Fehler im zugrunde liegenden Testprojekt lokalisieren, sondern auch multiple Fehler. Um dies zu ermöglichen, wird die erstellte TCM für die Fehlerberechnung partitioniert. Durch die Partitionierung der Matrix entstehen mehrere voneinander unabhängige Teilmatrizen, auf denen die Fehlerlokalisierung unabhängig von den anderen Partitionen ausgeführt werden kann. Das entspricht dem Prinzip der Teilung eines Problems in mehrere kleinere Probleme. So kann für jede dabei entstehende Teilmatrix eine separate Fehlerberechnung durchgeführt werden. Für nähere Informationen zur Organisation und Berechnung von Partitionen in EzUnit sei auf [SF10] verwiesen Die EzUnit Benutzeroberfläche Aus Eclipse heraus kann EzUnit analog zu JUnit im Kontextmenü eines Testfalls (einer Testklasse oder einer Testsuite), aufgerufen werden. EzUnit bringt verschiedene Views für Einstellungen und Ergebnisanzeige mit [EzU5], von denen hier zwei hervorgehoben werden sollen. Es handelt sich dabei um den EzUnit Result View und den EzUnit Matrix View (siehe Abbildung 6). Im unteren Teil der Darstellung befindet sich der EzUnit Result View und im oberen Teil ist der EzUnit Matrix View links neben dem bereits vorgestellten JUnit View zu sehen. Zur Illustration wurde die bereits in Abschnitt 2.3 (S. 4) vorgestellte Testklasse SimpleIntCalculatorTest mit EzUnit ausgeführt. Im EzUnit Matrix View ist zu erkennen, dass EzUnit drei Partitionen erzeugt hat, und aus welchen vier MUTs sich diese Partitionen zusammensetzen. Die MUTs befinden sich in der ersten Spalte des Views (mit Unit Under Test bezeichnet) unterhalb der jeweiligen Partitionsbezeichnung. Die Spalten rechts neben den MUTs repräsentieren die einzelnen Testmethoden, die für den Testlauf ausgeführt wurden. Aus Gründen der Übersichtlichkeit sind nicht die vollständigen Namen der Testmethoden als Spaltenüberschriften aufgeführt, sondern die in Java übliche Camelcase Notation, bei der jeweils nur die Großbuchstaben (bzw. Anfangszeichen) des Namens einer Testmethode berücksichtigt werden. So ergibt sich beispielsweise für die Testmethode testadd() die Spaltenüberschrift A. Partitionsnamen setzen sich aus den Camelcase Notationen der enthaltenen Testmethoden zusammen. So lautet der Name der Partition, die die Testmethoden testdivide() und testdividedbyzero() enthält Partition(D DBZ). 15

24 16 Abbildung 6: EzUnit Views

25 Die Ansicht im EzUnit Matrix View bildet eine TCM. Ob eine MUT durch eine Testmethode aufgerufen wurde, wird in der Matrix wie folgt illustriert. Ist das Feld der Matrix an der entsprechenden Stelle grün hinterlegt,wird eine MUT von der jeweiligen Testmethode ausgeführt, wobei die Testmethode fehlerfrei ist. Ist das Feld rot hinterlegt, wird die MUT von der jeweiligen Testmethode ausgeführt, wobei die Testmethode fehlerhaft war. Die fehlerfreie Testmethode testdivide() (D) führt beispielsweise die MUT SimpleIntCalculator.divide(..) aus, die fehlerhafte Testmethode testsubstract() (S) die MUT SimpleIntCalculator.substract(..) welche ebenfalls von Testmethode testaddandsubstract() (AAS) ausgeführt wird. Ein weißer bzw. grauer Feldhintergund bedeutet, dass die MUT von einer Testmethode nicht ausgeführt wurde. Die Unterscheidung von weiß und grau hängt damit zusammen, ob eine Testmethode in der jeweiligen Partition enthalten ist (grau) oder nicht (weiß), vgl. hierzu [SF10]. Der EzUnit Matrix View unterscheidet verschiedene Modi nach denen die Partitionierung in EzUnit erfolgen soll. Es handelt sich dabei um die Modi Failed, Passed, All und All (only with failed), die im oberen Bereich des Views auswählbar sind. Für diese Arbeit konzentrieren sich alle Untersuchungen auf den Modus All bei dem alle Testmethoden für die Matrixbildung berücksichtigt werden, unabhängig davon, ob sie mit einem positiven Ergebnis ausgewertet wurden (Passed) oder mit einem Fehler beendet wurden (Failed) [EzU5]. Die Anzeige im EzUnit Result View wird ebenfalls nach Partitionen organisiert, hierfür werden allerdings nur Partitionen erzeugt die fehlerhafte Testmethoden enthalten, in diesem Beispiel also eine Partition (DBZ) und eine Partition (AAS S). Die in den Partitionen enthaltenen MUTs können aufgeklappt werden, um die aufrufenden Testmethoden anzuzeigen. In den Spalten neben den MUTs befinden sich die berechneten Werte der ausgewählten Fehlerlokatoren. In diesem Fall sind es die Fehlerlokatoren FIS (Find In Source), FA (Failure Accountability), FC (Failure Counter), FR (Failure Ratio), O (Ochiai), SMUT (Single MUT) und T (Tarantula) (vgl. [Ber10, SF10, SEES08, EzU5]). Diese lassen sich beliebig konfigurieren. Die angezeigten Werte geben die Verdächtigkeit für jede MUT an. Der Wert kann je nach Fehlerlokator sehr unterschiedlich sein. In der ersten Spalte des EzUnit Result View (mit Avg bezeichnet) wird jeweils der von EzUnit ermittelte globale Wert für die Verdächtigkeit einer MUT angezeigt. Im EzUnit Matrix View wird pro Zeile der Matrix nur die globale Verdächtigkeit angegeben (vgl. Spalte L). Der von EzUnit errechnete globale Verdächtigkeitswert wird visuell durch die Hintergrundfarbe der Spalte L (im EzUnit Matrix View) bzw. der Zeile in dem die MUT steht (im EzUnit Result View) hervorgehoben. Rot ist dabei der stärkste Wert, der die Verdächtigkeit mit einer Wahrscheinlichkeit nahe 1.00 angibt. Es erfolgt eine graduelle Abstufung der Farbwerte über die Farben Orange, Gelb und schließlich Grün, welches der schwächste Wert ist. Er drückt die Verdächtigkeit mit einer Wahrscheinlichkeit nahe 0.00 aus [Ber10]. 17

26 Neben den bereits beschriebenen Informationen finden sich im oberen Bereich des EzUnit Result Views auch Informationen allgemeiner Natur, wie die Anzahl der Testfälle, aufgeteilt in Failed tests und Passed tests, sowie die Anzahl der ermittelten MUTs. Wie man sieht, korrespondiert die Zahl von vier MUTs mit den vier dargestellten MUTs im EzUnit Matrix View (für den Modus All) und die Anzahl Failed tests und Passed tests entspricht jeweils in Summe der Anzahl Runs des JUnit Views. Die Anzahl Failed tests korrespondiert mit der Summe aus JUnit Errors und Failures. Für nähere Informationen zur EzUnit Benutzeroberfläche sei an dieser Stelle auf die Beschreibungen der EzUnit Projektseite [EzU5] verwiesen JUnit als Testprojekt Da beim Tracing des Testlaufs nicht nur die besuchten Testfälle und Quelltextmethoden aufgezeichnet werden, sondern auch die Methoden des Frameworks, die für die Testausführung genutzt werden, ergibt sich bei der Verwendung von JUnit als Testprojekt für EzUnit die folgende Problematik. Durch die Filterfunktion von EzUnit werden die Methodenaufrufe des Tracings bereinigt und Systemroutinen vor der Fehlerberechnung aussortiert. Im Fall von JUnit als Testprojekt versagen diese Filter jedoch. Es ist nicht mehr erkennbar, ob die Methoden nun zum getesteten Projekt oder zum Testframework gehören, da sowohl die Methoden für die Testausführung als auch die Methoden des Testprojektes die gleiche Paket-Struktur besitzen. Betrachtet man das Beispiel der Assert Methoden, so würde durch die Standard- Filter von EzUnit jeder Aufruf einer Assert Methode als MUT ausgeschlossen werden. EzUnit würde die Methode als Systemroutine erkennen. Wenn es aber nun Testfälle gibt, die als zugrunde liegende Testeinheit eine der Assert Methoden überprüfen, so wäre dieser Ausschluss nicht korrekt. Aufgabe dieser Arbeit ist es, diese Problematik genauer zu analysieren und eine Lösungsmöglichkeit zu finden, um JUnit als Testprojekt für EzUnit verwenden zu können. 18

27 3 Problemerfassung Die Problemerfassung behandelt die eingehende Analyse des Verhaltens von EzUnit unter Verwendung von JUnit als Testprojekt. Zunächst wird das Vorgehen zur Problemerfassung im Detail erläutert und anschließend die vorgefundenen Ergebnisse vorgestellt und diskutiert. 3.1 Vorgehen Um einen umfassenden Einblick in die Problematik zu erhalten, werden sowohl JUnit 3 als auch JUnit 4 als Testprojekte für EzUnit herangezogen. Die Quelltexte der Projekte und die zugehörigen Tests können unter [JU3S, JU3T, JU4] heruntergeladen werden. Da EzUnit dafür ausgerichtet ist Fehler in Testprojekten zu lokalisieren, reicht die Betrachtung der Originalprojekte an dieser Stelle nicht aus. Um eine eingehendere und umfangreichere Analyse zu ermöglichen, wurden von beiden Projekten Kopien erstellt, in die an verschiedenen Stellen im Quelltext Fehler injiziert wurden. Im Folgenden werden nun sowohl die original belassenen Projekte als auch die mit Fehlern injizierten Projekte betrachtet und mit EzUnit getestet. Um das Verhalten von EzUnit für JUnit als Testprojekt zu untersuchen, wurden die originalen Projekte zusammen mit ihren Testfällen in den Eclipse Workspace importiert und eine JUnit Library zum Klassenpfad hinzugefügt. Dabei wurde für JUnit 3 eine JUnit Library in der Version eingebunden und für JUnit 4 eine JUnit Library in der Version Für JUnit 4 ist darüber hinaus noch das Einbinden der Klassenbibliothek Hamcrest erforderlich. Da das JUnit 4 Projekt ein Maven Projekt ist, wurde die dort verwendete Maven Paket- Struktur auch für das JUnit 3 Projekt übernommen. Die von Maven vorgegebene Paket- Struktur ist dahingehend genormt, dass sich alle Quelltexte im Quelltextverzeichnis src/main/java befinden und alle Tests im Quelltextverzeichnis src/test/java. Für nähere Informationen zu Maven sei auf [OCP09] verwiesen. Um eine genauere Analyse zu ermöglichen, wurde EzUnit für die Tests nicht nur als Eclipse Plug-in eingebunden, sondern das EzUnit Plug-in Projekt aus der Entwicklungsumgebung heraus ausgeführt. Hierfür wurden die Quelltexte des EzUnit-Plug-in Projektes in das Eclipse PDE (vgl. Abschnitt 2.2, S. 3) eingebunden und ausgeführt. So war es möglich, die Testergebnisse nicht nur anhand der EzUnit Views abzulesen, sondern es wurden zusätzlich an einigen Stellen im EzUnit Quelltext Logausgaben implementiert, um nähere Informationen über die in den Views dargestellten Ergebnisse zu erhalten (siehe Abschnitt 3.1.3, S. 22). Weitere Informationen zu Eclipse Plug-ins finden sich beispielsweise in [CR08]. 19

28 3.1.1 Referenztestfälle Um ein möglichst aussagekräftiges Ergebnis über die Testdurchläufe zu erhalten, sollte durch die verwendeten Referenztestfälle für die folgenden Untersuchungen eine möglichst hohe Testabdeckung auf den untersuchten Projekten gewährleistet sein. Hierfür eignen sich insbesondere die in den Tests zu den Projekten JUnit 3 und JUnit 4 enthaltenen Testsuites AllTests.java, die für JUnit 3 im Paket junit.tests liegen und für JUnit 4 im Paket org.junit.tests. Die Verwendung der Testsuites erlaubt ein einfaches Ausführen der Testfälle über die Benutzeroberfläche und gewährleistet, dass für jeden Testlauf die gleichen Testfälle ausgeführt werden. Die Testsuite aus dem Paket org.junit.tests, die für JUnit 4 ausgeführt wird, ruft die ebenfalls in den Tests zum Projekt enthaltene Testsuite aus dem Paket junit.tests mit auf. Es gilt dabei, dass Testfälle aus dem Paket org.junit.tests die Quelltexte aus dem Paket org.junit abdecken, und die Testfälle aus dem Paket junit.tests die Quelltexte aus dem Paket junit. Auch wenn durch die Ausführung der Testsuites nicht alle in den Projekten enthaltenen Testfälle ausgeführt werden, so ist doch eine repräsentativ große Auswahl an Testfällen gegeben. Die Testfälle können zudem mit wenig Aufwand ausgeführt werden, da lediglich eine Testsuite pro Projekt aufgerufen werden muss [TLMG11]. Außerdem ist die wichtige Eigenschaft erfüllt, dass die Testfälle im Originalzustand und auf den originalen Projekten ausgeführt alle fehlerfrei durchlaufen. Die Testsuite junit.tests.alltests.java, die für JUnit 3 ausgeführt wird, enthält insgesamt 103 Testfälle, die Testsuite org.junit.tests.alltests.java, die für JUnit 4 ausgeführt wird, insgesamt Fehler-Injizierung Für die Problemerfassung wurden Kopien der originalen JUnit Projekte erstellt und mit Fehlern versehen, indem an verschiedenen Stellen im Quelltext kleine Veränderungen vorgenommen wurden. Dies hat zur Folge, dass die ausgewählten Referenztestfälle nicht mehr fehlerfrei ausgeführt werden können. Insgesamt wurden vier neue JUnit Projekte erstellt, die mit Fehlern versehen wurden. Dabei handelt es sich um zwei Kopien des JUnit 3 Projektes und um zwei Kopien des JUnit 4 Projektes. Die Kopien der Projekte werden anhand der injizierten Fehler unterschieden. Sie werden als Spezialfall Assert und allgemeiner Fehlerfall (jeweils für JUnit 3 und JUnit 4 ) bezeichnet. Die Unterscheidung dieser beiden Formen wird damit begründet, dass das Fehlerverhalten der als Spezialfall Assert bezeichneten Projekte deutlich von denen als allgemeiner Fehlerfall bezeichneten Projekten abweicht. Es sei an dieser Stelle auf die nähere Ausführung in Abschnitt 3.2 (S. 25) verwiesen. Alle Testprojekte sind auf der CD zu dieser Arbeit enthalten (siehe Anhang B, S. 82). 20

29 Im Folgenden werden die Methoden der verschiedenen Klassen, in die Fehler injiziert wurden, kurz aufgelistet. Modifizierte Klassen - allgemeiner Fehlerfall JUnit 3 junit.runner.basetestrunner.getpreferences() junit.textui.resultprinterprintdefects(enumeration booboos, int count, String type) junit.runner.classpathtestcollector.collectfilesinroots(vector roots) junit.framework.comparisonfailure.getmessage() Modifizierte Klassen - Spezialfall Assert JUnit 3 junit.framework.assert.asserttrue(string message, boolean condition) Modifizierte Klassen - allgemeiner Fehlerfall JUnit 4 junit.runner.basetestrunner.getpreferences() junit.textui.resultprinterprintdefects(enumeration booboos, int count, String type) junit.framework.comparisonfailure.getmessage() org.junit.rules.testname.getmethodname() org.junit.internal.assumptionviolatedexception.describeto(description description) Modifizierte Klassen - Spezialfall Assert JUnit 4 junit.framework.assert.asserttrue(string message, boolean condition) org.junit.assert.asserttrue(string message, boolean condition) Die Klassen und Methoden, in die Fehler injiziert wurden, sind willkürlich gewählt. Sie dienen lediglich dazu, zu illustrieren, wie sich JUnit im Selbsttest verhält. Um eine möglichst gute Übersicht über die Fehler in den EzUnit Views zu behalten, beschränkt sich diese Arbeit auf die Injizierung weniger Fehler. 21

30 3.1.3 Logausgaben Um die Analyse der Ergebnisse zu vereinfachen, wurden an zwei verschiedenen Stellen im EzUnit Quelltext Logausgaben implementiert. So wird zum einen die Stelle durch Logausgaben überwacht, an denen die Daten für den EzUnit Matrix View bereitgestellt werden, und zum anderen die Stelle, an der die Daten für den EzUnit Result View ausgegeben werden. Die im folgenden beschriebenen Änderungen wurden nicht mit in den Quelltext des EzUnit Plug-in Projektes übernommen, sondern nur in einer Kopie des Projektes für diese Arbeit implementiert. Die modifizierte Kopie des EzUnit Plug-in Projektes findet sich auf der CD, die dieser Arbeit beiliegt (siehe Anhang B, S. 82). Die Ergebnisse des EzUnit Result Views werden in der Klasse org.projectory.ezunit. core.runmanager bereitgestellt. Die Codezeilen 242 bis 245 (Revision * :00) sind in Listing 3 dargestellt und liefern die für die Logausgaben interessanten Informationen. Die Variable muts ist dabei ein Array vom Typ MethodUnderTest, in dem MUTs vorgehalten werden und die Variablen failedtests und passedtests sind Collections mit Elementen vom Typ TestMethod, die zur Speicherung von fehlgeschlagenen bzw. als korrekt ausgewerteten Testmethoden dienen. 1 // c a l c u l a t e the t e s t i n f o r m a t i o n s 2 t e s t I n f o s. addinfo ( MUTs, + muts. length ) ; 3 t e s t I n f o s. addinfo ( F a i l e d t e s t s, + f a i l e d T e s t s. s i z e ( ) ) ; 4 t e s t I n f o s. addinfo ( Passed t e s t s, + passedtests. s i z e ( ) ) ; Listing 3: Zeilen 242 bis 245 der Klasse RunManager Die Klasse MethodUnderTest stellt Methoden zur Verfügung (getdisplayname() und getfullname()), um den Namen einer MUT auszugeben. Für die Logausgaben wurde das Array muts iteriert, die MUTs wurden gezählt, und ihre Namen ausgegeben (siehe Listing 4, Zeile 6-11). Bei den Untersuchungen für diese Arbeit stellte sich heraus, dass das Array wider Erwarten nicht nur MUTs, sondern auch Testmethoden enthält, die ebenfalls als MUTs ausgegeben werden (vgl. Zeile 2 aus Listing 3). Somit ist die ausgegebene Anzahl MUTs im EzUnit Result View nicht korrekt. Um die tatsächliche Anzahl MUTs auszugeben, wurden die im Array muts gespeicherten Methoden zunächst mittels der Methode istest() überprüft. Die Methode istest() der Klasse MethodUnderTest gibt true zurück, wenn es sich bei der überprüften Methode um eine Testmethode handelt. Die Anzeige im EzUnit Result View wurde für die Erstellung dieser Arbeit korrigiert. Listing 4 zeigt die vorgenommenen Änderungen. Zeile 1 entspricht dabei Zeile 1 aus Listing 3, und die Zeilen 2, 3 und 4 aus Listing 3 den Zeilen 14, 16 und 22 aus Listing 4. Neben den MUTs des EzUnit Result Views werden noch die fehlerhaften und nicht fehlerhaften Testmethoden gezählt und als Logeintrag ausgegeben. Zeile 19 zeigt die Ausgabe der fehlerhaften Testfälle und Zeile 25 die Ausgabe der fehlerfreien Testfälle. 22

31 1 // c a l c u l a t e the t e s t i n f o r m a t i o n s 2... // i n i t i a l i z e l o g g i n g 3 int mcounter = 0 ; // counter f o r muts 4 int tcounter = 0 ; // counter f o r testmethods 5 6 for ( MethodUnderTest mut : muts ) { 7 i f (! mut. i s T e s t ( ) ) { 8 mcounter++; // l o g e n t r y f o r mut 9 l o g g e r. i n f o ( M + mcounter + ) + mut. getdisplayname ( ) + + mut. getfullname ( ) ) ; 10 } 11 } t e s t I n f o s. addinfo ( MUTs, + mcounter ) ; // c o r r e c t e d value! 14 // t e s t I n f o s. addinfo ( MUTs, + muts. length ) ; t e s t I n f o s. addinfo ( F a i l e d t e s t s, + f a i l e d T e s t s. s i z e ( ) ) ; 17 for ( TestMethod ftest : f a i l e d T e s t s ) { 18 tcounter++; // l o g e n t r y f o r testmethod 19 l o g g e r. i n f o ( T + tcounter + ) + ftest. getname ( ) ) ; 20 } t e s t I n f o s. addinfo ( Passed t e s t s, + passedtests. s i z e ( ) ) ; 23 for ( TestMethod ptest : passedtests ) { 24 tcounter++; // l o g e n t r y f o r testmethod 25 l o g g e r. i n f o ( T + tcounter + ) + ptest. getname ( ) ) ; 26 } Listing 4: Logausgaben und Korrektur in der Klasse RunManager Die Ergebnisse des EzUnit Matrix Views werden in der Klasse org.projectory.ezunit. matrixview.matrixcontentprovider bereitgestellt. Für diese Arbeit wurde lediglich die Ausgabe für die Einstellung All im EzUnit Matrix View modifiziert (vgl. hierzu Abschnitt 2.4, S. 12). Die Informationen für diese Ansicht werden in Zeile der Klasse MatrixContentProvider (Revision * :00) bereitgestellt. Sie sind in Listing 5 zu sehen. 1 e l s e i f ( showtestsmode == ShowTestsMode. ALL ) 2 return P a r t i t i o n S t o r e. g e t I n s t a n c e ( ). getmutpartitions ( ). toarray ( ) ; Listing 5: Zeilen 60 und 61 der Klasse MatrixContentProvider Die Klasse org.projectory.ezunit.core.partition.partitionstore gibt über die Methode getmutpartitions() eine Liste von Partitionen (Klasse org.projectory. ezunit.core.partition.partition) zurück. Eine Partition speichert Informationen über die enthaltenen MUTs und Testmethoden. 23

32 Listing 6 zeigt Auszüge der Implementierung für die Logausgaben des EzUnit Matrix Views und wird im Folgenden näher erläutert. Zeile 1 entspricht dabei Zeile 1 aus Listing 5 und Zeile 28 entspricht Zeile 2 aus Listing 5. Für die Logausgaben werden die Partitionen zunächst iteriert und alle in ihnen enthaltenen MUTs ermittelt (vgl. Zeile 7-11). Anschließend werden die Namen der MUTs sowie ein Zähler ausgegeben. Dabei wird zunächst überprüft, ob es sich bei der gefundenen MUT um eine Testmethode handelt. Sollte dies der Fall sein, wird die Testmethode gesondert ausgezeichnet ausgegeben, der Zähler aber nicht inkrementiert (vgl. Zeile 18). 1 e l s e i f ( showtestsmode == ShowTestsMode. ALL ) { int mcounter = 0 ; // mut counter 4 int tcounter = 0 ; // t e s t counter 5 6 Object [ ] array = P a r t i t i o n S t o r e. g e t I n s t a n c e ( ). getmutpartitions ( ). toarray ( ) ; 7 for ( Object p L i s t : array ) { // i t e r a t e p a r t i t i o n s 8 P a r t i t i o n <MethodUnderTest> p = 9 ( P a r t i t i o n <MethodUnderTest>) p L i s t ; 10 l o g g e r. i n f o ( +p ) ; 11 for ( MethodUnderTest mutinp : p. uuts ) { // i t e r a t e muts in p a r t i t i o n p 12 i f (! mutinp. i s T e s t ( ) ) { 13 mcounter++; 14 l o g g e r. i n f o ( M + mcounter + ) + 15 mutinp. getdisplayname ( ) + + mutinp. getfullname ( ) ) ; 16 } 17 else { 18 l o g g e r. i n f o ( ) + mutinp. getdisplayname ( ) + + mutinp. getfullname ( ) ) ; 19 } 20 } for ( TestMethod testinp : p. t e s t s L i s t ) { // i t e r a t e t e s t s in p a r t i t i o n p 23 tcounter++; 24 l o g g e r. i n f o ( T + tcounter + ) + testinp. getname ( ) ) ; 25 } 26 } return P a r t i t i o n S t o r e. g e t I n s t a n c e ( ). getmutpartitions ( ). toarray ( ) ; 29 } Listing 6: Logausgaben in der Klasse MatrixContentProvider 24

33 Die Testmethoden werden in den Partitionen in einer Liste von org.projectory.ezunit. core.testmethod.testmethod Objekten gespeichert, diese Liste wird ebenfalls iteriert und mit einem Zähler ausgegeben (vgl. Zeilen 22-24). 3.2 Analyse Im Folgenden werden die Ergebnisse der Analyse beim Durchlauf von EzUnit Tests auf den vorgestellten JUnit Testprojekten dokumentiert. Als Ausgangspunkt dient dabei jeweils das Ergebnis, das bei einem reinen JUnit Testlauf ermittelt wird. Darüber hinaus werden die Erwartungshaltungen an das Testergebnis von EzUnit mit dem tatsächlichen Ergebnis abgeglichen. Die folgenden Aussagen über ein EzUnit Ergebnis dienen dabei als Vorgabe für ein erwartetes Analyseergebnis. Sie sind an die Erläuterungen aus Abschnitt (S. 15) angelehnt. Erwartungen an das Ergebnis eines EzUnit Laufs (vgl. hierzu Abbildung 6, S. 16) Die Anzahl der Testfälle im EzUnit Matrix View entspricht der Anzahl Runs im JUnit View. Die Summe von Errors und Failures im JUnit View entspricht der Anzahl Failed tests im EzUnit Result View. Die Anzahl Runs minus der Summe Errors und Failures im JUnit View entspricht der Anzahl Passed tests im EzUnit Result View. Mindestens alle Methoden, in die Fehler injiziert wurden, (vgl. Abschnitt 3.1.2, S. 20) müssen im EzUnit Result View aufgelistet und mit einem entsprechenden Verdächtigkeitswert ausgewiesen sein. Alle ausgeführten Testmethoden müssen im EzUnit Matrix View in der erstellten Matrix berücksichtigt sein und die Anzahl der verwendeten MUTs muss mit der errechneten Anzahl MUTs im EzUnit Result View übereinstimmen. Sind keine Fehler im Projekt enthalten, werden die erstellten Partitionen im EzUnit Matrix View grün (bzw. grau) gefärbt, und der Verdächtigkeitswert der ermittelten MUTs wird mit NaN angegeben. Außerdem wird keine Matrix im EzUnit Result View dargestellt. Zur Illustration ist auf S. 81 in Abbildung 13 ein solches EzUnit Ergebnis ohne Fehler zu sehen. Das zugehörige Beispielprojekt ist auf der beiliegenden CD (vgl. Anhang B, S. 82) zu finden. Es handelt sich dabei um eine fehlerfreie Version der bereits vorgestellten Beispieltestklasse SimpleIntCalculatorTest (vgl. Listing 1, S. 8). Abgeglichen werden die erwarteten Ergebnisse mit den durch die Logausgaben und die Ergebnisdarstellung der Benutzeroberfläche von EzUnit ermittelten Werte. Zu Dokumentationszwecken sind die Screenshots der Testergebnisse aller EzUnit Durchläufe auf der CD, die dieser Arbeit beiliegt, zu finden (vgl. Anhang B, S. 82). Dort sind auch alle Logausgaben zu den jeweiligen Testergebnissen zu finden. 25

34 3.2.1 Testprojekt JUnit 3 ohne Fehler Beim Testprojekt JUnit 3 ohne Fehler handelt es sich um das original belassene JUnit 3 Projekt. Es wird als Testergebnis erwartet, dass alle 103 Testfälle des Projektes fehlerfrei beendet und entsprechend im EzUnit Matrix View zusammen mit den aufgerufenen MUTs dargestellt werden. Da keine Fehler angenommen werden, ist im EzUnit Result View keine Darstellung zu erwarten, da keine Partitionen mit fehlerhaften Testfällen erstellt werden können. Die Wahrscheinlichkeit, dass eine MUT fehlerhaft ist, sollte überall NaN sein und das Ergebnis sollte sich in einer grünen Matrixfärbung im EzUnit Matrix View widerspiegeln. Tabelle 2 fasst die wesentlichen Ergebnisse zusammen. Tabelle 2: Ergebnisse Analyse Testprojekt JUnit 3 ohne Fehler JUnit EzUnit Result View Result View Matrix View Runs Errors Failures MUTs Failed Passed MUTs Testfälle Obwohl der EzUnit Result View auf den ersten Blick keine Auffälligkeiten aufweist, so finden sich doch im EzUnit Matrix View einige Unstimmigkeiten. Von EzUnit wurden insgesamt sechs Partitionen erstellt. Diesen liegen allerdings von den eigentlich 103 Testfällen nur 29 zugrunde. Auch von den berechneten 72 MUTs aus dem EzUnit Result View, wurden im EzUnit Matrix View nur 68 berücksichtigt, außerdem befindet sich unter den MUTs eine Testmethode, was zusammen die 69 von EzUnit ermittelten MUTs ergibt. Bei der Testmethode handelt es sich um die Methode junit.tests.framework.noargtestcasetest.testnothing() die fälschlicherweise von EzUnit als MUT erkannt wurde Testprojekt JUnit 4 ohne Fehler Beim Testprojekt JUnit 4 ohne Fehler handelt es sich um das original belassene JUnit 4 Projekt. Die erwarteten Ergebnisse sind nahezu identisch mit den in Abschnitt beschriebenen. Lediglich die Anzahl der Testfälle unterscheidet sich. Für das JUnit 4 Projekt werden 582 Testfälle erwartet. Tabelle 3 zeigt die wichtigsten Analyseergebnisse. 26

35 Tabelle 3: Ergebnisse Analyse Testprojekt JUnit 4 ohne Fehler JUnit EzUnit Result View Result View Matrix View Runs Errors Failures MUTs Failed Passed MUTs Testfälle 582 (3 ignored) Wie zuvor schon für das JUnit 3 Projekt beschrieben, werden nicht alle Testfälle im EzUnit Matrix View bei der Erzeugung der Partitionen berücksichtigt. Insgesamt werden 15 Partitionen erstellt, unter Berücksichtigung von 47 anstelle von 582 Testfällen. Auch die Anzahl MUTs im EzUnit Result View und im EzUnit Matrix View differiert. Von den 107 errechneten MUTs werden nur 79 in die Matrixbildung einbezogen. Zu diesen 79 MUTs wurde auch wieder die Testmethode junit.tests.framework. NoArgTestCaseTest.testNothing() gezählt, was eine Gesamtzahl von 80 MUTs ergibt. Für die Testergebnisse von JUnit 4 im Speziellen lässt sich beobachten, dass sich alle berücksichtigten Testmethoden und MUTs ausschließlich im Paket junit befinden. Ez- Unit hat keine Testmethoden und MUTs aus dem Paket org.junit berücksichtigt. Außerdem finden sich in der gebildeten Matrix des EzUnit Matrix Views Methoden unter den MUTs, die aus dem Quelltextverzeichnis stammen, das für Tests vorgesehen ist (vgl. Abbildung 5, S. 14). Diese sollten aufgrund der Standard-Filterfunktionen von Ez- Unit aber nicht als MUTs ausgewertet werden. Eine weitere Auffälligkeit ist die Anzahl der Testmethoden, die von EzUnit im EzUnit Result View angezeigt wird. Sie stimmt nicht mit der ermittelten Anzahl an Testmethoden von JUnit überein. JUnit ermittelt insgesamt 582 Testmethoden, EzUnit lediglich Testprojekt JUnit 3 mit injizierten Fehlern Unter der Bezeichnung JUnit 3 mit injizierten Fehlern werden im folgenden die beiden Testprojekte allgemeiner Fehlerfall JUnit 3 und Spezialfall Assert JUnit 3 untersucht. In die Projekte wurden die in Abschnitt (S. 20) beschriebenen Fehler injiziert. Dabei wurden beim Projekt allgemeiner Fehlerfall JUnit 3 insgesamt vier Fehler in die folgenden Klassen injiziert: junit.runner.basetestrunner, junit.textui.resultprinter, junit.runner.classpathtestcollector und junit.framework.comparisonfailure. Das Projekt Spezialfall Assert JUnit 3 enthält lediglich einen injizierten Fehler in der Klasse junit.framework.assert. Bei einem JUnit Testlauf wurden beim Testprojekt allgemeiner Fehlerfall JUnit 3 von den 103 Testfällen sieben mit einem Failure und einer mit einem Error beendet. Alle anderen Testfälle wurden erfolgreich beendet. Beim Testprojekt Spezialfall Assert JUnit 3 wurden alle 103 Testfälle mit einem Failure beendet. Keiner der Testfälle lief fehlerfrei. Dieses zugrundeliegende JUnit Ergebnis erzeugt folgende Erwartungshaltung an das EzUnit Ergebnis. Es wird angenommen, dass die Anzahl an fehlerhaften und fehlerfreien 27

36 Testfällen jeweils mit der von JUnit ermittelten Anzahl übereinstimmt. Darüber hinaus wird eine Matrix im EzUnit Result View erwartet. Es muss mindestens vier fehlerhafte MUTs für das Projekt allgemeiner Fehlerfall JUnit 3 und mindestens eine fehlerhafte MUT für das Projekt Spezialfall Assert JUnit 3 geben. In Tabelle 4 sind die Ergebnisse der Testläufe einander gegenübergestellt. Tabelle 4: Ergebnisse Analyse Testprojekt JUnit 3 mit injizierten Fehlern JUnit EzUnit injizierte Result View Result View Matrix View Fehler Runs Errors Failures MUTs Failed Passed MUTs Testfälle vier eins Für das Projekt allgemeiner Fehlerfall JUnit 3 ist auffällig, dass von den vier Methoden, in die Fehler injiziert wurden, lediglich drei mit einem Verdächtigkeitswert größer null (0.00 ) von EzUnit ermittelt wurden. Dabei handelt es sich um die Methoden der Klassen junit.runner.basetestrunner, junit.textui.resultprinter und junit. runner.classpathtestcollector. Die Klasse junit.framework.comparisonfailure wurde dagegen nicht bei der Fehlerlokalisierung berücksichtigt. Bei näherer Betrachtung fällt auf, dass keine der Methoden aus dem Paket junit. framework bei der Matrixbildung berücksichtigt wurde. Es werden keine MUTs aus diesem Paket ermittelt. Das gilt sowohl für die Matrix aus dem EzUnit Result View als auch aus dem EzUnit Matrix View. Neben diesen Beobachtungen können die gleichen Probleme ausgemacht werden, wie in Abschnitt (S. 26) beschrieben: Im Ez- Unit Matrix View werden nicht alle Testfälle und MUTs berücksichtigt und unter den MUTs befindet sich die Testmethode NoArgTestCaseTest.testNothing() aus dem Paket junit.tests.framework. Beim Testprojekt Spezialfall Assert JUnit 3 wird nun ersichtlich, warum dieser Fall gesondert behandelt werden muss. EzUnit führt überhaupt keine Partitionierung durch. Der EzUnit Matrix View ist leer und auch im EzUnit Result View wird keine Matrix zur Fehlerlokalisierung erstellt. Lediglich die allgemeinen Angaben Anzahl MUTs, Failed tests und Passed tests werden von EzUnit dargestellt Testprojekt JUnit 4 mit injizierten Fehlern Beim Testprojekt JUnit 4 mit injizierten Fehlern handelt es sich um die Untersuchung der beiden Testprojekte allgemeiner Fehlerfall JUnit 4 und Spezialfall Assert 3 Testprojekt allgemeiner Fehlerfall JUnit 3 4 Testprojekt Spezialfall Assert JUnit 3 28

37 JUnit 4. Auch bei diesen beiden Testprojekten wurden im Quelltext an verschiedenen Stellen Fehler injiziert (vgl. Abschnitt 3.1.2, S. 20). Beim allgemeinen Fehlerfall JUnit 4 wurden insgesamt fünf Fehler injiziert. Betroffen sind Methoden der folgenden Klassen: junit.runner.basetestrunner, junit.textui.resultprinter, junit. framework.comparisonfailure, org.junit.rules.testname und org.junit. internal.assumptionviolatedexception. Beim Testprojekt Spezialfall Assert JUnit 4 wurden insgesamt zwei Fehler injiziert: einer in eine Methode der Klasse junit. framework.assert und einer in eine Methode der Klasse org.junit.assert. Bei einem reinen JUnit Testlauf des Projektes allgemeiner Fehlerfall JUnit 4 wurden von den 582 Testfällen einer mit einem Error und 13 mit einem Failure beendet. Beim Testprojekt Spezialfall Assert JUnit 4 wurden von den 582 Testfällen fünf mit einem Error und 214 mit einem Failure beendet. Die sich daraus ergebende Erwartungshaltung an das Ergebnis des EzUnit Testlaufs ist identisch mit der in Abschnitt (S. 27) bereits für das Testprojekt JUnit 3 mit injizierten Fehlern beschriebenen. Lediglich die Anzahl der Fehler ist entsprechend anzupassen. In Tabelle 5 sind die Ergebnisse der beiden Testläufe zu sehen. Tabelle 5: Ergebnisse Analyse Testprojekt JUnit 4 mit injizierten Fehlern JUnit EzUnit injizierte Result View Result View Matrix View Fehler Runs 7 Errors Failures MUTs Failed Passed MUTs Testfälle fünf zwei Beim Ergebnis des Testprojektes allgemeiner Fehlerfall JUnit 4 wurden von den im Paket junit injizierten drei Fehlern nur zwei im EzUnit Result View als fehlerhaft lokalisiert. Dabei handelt es sich um die fehlerhaften Methoden der Klassen junit.runner. BaseTestRunner und junit.textui.resultprinter. Analog zum beobachteten Verhalten in Abschnitt (S. 27) wurde der in einer Methode des junit.framework Paketes injizierte Fehler nicht lokalisiert. Auch im EzUnit Matrix View finden sich weder bei den Testmethoden, noch bei den MUTs der erstellten Partitionen, Methoden aus diesem Paket. Die Fehler, die in Methoden der Klassen aus dem Paket org.junit injiziert wurden, werden ebenfalls nicht im EzUnit Result View berücksichtigt. 5 Testprojekt allgemeiner Fehlerfall JUnit 4 6 Testprojekt Spezialfall Assert JUnit 4 7 davon je 3 ignored vgl. hierzu Tabelle 3, S

38 Eine genauere Untersuchung der für die Partitionierung berücksichtigten Testmethoden und MUTs zeigt, dass in keiner der erzeugten Matrizen der beiden EzUnit Views Methoden aus dem Paket org.junit berücksichtigt werden. Außerdem befinden sich, wie bereits in Abschnitt (S. 26) beschrieben, wieder Methoden aus dem für Tests vorgesehenen Quelltextverzeichnis unter den MUTs. Für das Testprojekt Spezialfall Assert JUnit 4 ergibt sich das gleiche Ergebnis wie für das Projekt Spezialfall Assert JUnit 3 (vgl. Abschnitt 3.2.3, S. 27). Neben den allgemeinen Angaben Anzahl MUTs, Failed tests und Passed tests werden keine weiteren Informationen im EzUnit Result View dargestellt. Eine Matrixbildung im EzUnit Matrix View findet ebenfalls nicht statt. Die Anzahl an ermittelten Testmethoden von JUnit und EzUnit (im EzUnit Result View) stimmt auch für die beiden Projekte JUnit 4 mit injizierten Fehlern nicht überein (vgl. hierzu 3.2.2, S. 26). 3.3 Auswertung der Analyseergebnisse In diesem Abschnitt werden die Analyseergebnisse der letzten Abschnitte im Detail betrachtet und ausgewertet. Die Ergebnisse dienen als Grundlage für einen Lösungsansatz, mit dessen Umsetzung und Evaluierung sich die nächsten beiden Abschnitte beschäftigen. Eine wichtige Beobachtung, die in den Analyseergebnissen für alle getesteten Projekte angestellt werden konnte, war die Tatsache, dass in keinem der getesteten Projekte eine Fehlerlokalisierung bzw. Matrixbildung für die Methoden der Pakete junit.framework und org.junit stattgefunden hat. Auch Testmethoden aus dem Paket org.junit wurden nicht berücksichtigt. Dies ist durch die bereits in Abschnitt 2.4 (S. 12) erläuterte Filterfunktion von EzUnit zu begründen. Die Filter verhindern, dass MUTs aus diesen Paketen für die Matrixbildung verwendet werden. Somit kann für diese Methoden auch keine Fehlerlokalisierung stattfinden. Verantwortlich für die Umsetzung dieser Filterregeln ist die Methode newline(..) der Klasse org.projectory.ezunit.core.trace.ezserver. Ein Ausschnitt der Codezeilen 462 ff. der Klasse EzServer (Revision * :34) ist in Listing 7 dargestellt. 1 i f ( method!= null 2 && method. e x i s t s ( ) 3 &&! excluded ( l i n e ) 4 && ( istestmethod 5! excludedpackagefragmentroot (... ) 6 ) { 7... // mut or testmethod found 8 } else... Listing 7: Ausschnitt der Methode newline(..) der Klasse EzServer 30

39 Die Methode excluded(..) (Zeile 3) überprüft, ob sich die beim Tracing ermittelte Methode in einem der als Exclude Packages angegebenen Pakete befindet (vgl. Abbildung 5, S. 14). Ist das der Fall, wird die Methode nicht als MUT oder Testmethode berücksichtigt. Eine weitere Auffälligkeit, die in den letzten Abschnitten herausgestellt wurde, ist die Tatsache, dass sich unter den MUTs in den von EzUnit gebildeten Matrizen zur Fehlerlokalisierung auch Testmethoden bzw. Methoden aus dem unter Exclude Source Folders definierten Quelltextverzeichnis befinden (vgl. Abschnitt 2.4, S. 12). Nach eingehender Untersuchung des EzUnit Plug-in Projektes hat sich herausgestellt, dass die Maven Paket-Struktur nicht für EzUnit Projekte verwendet werden kann (vgl. Abschnitt 3.1, S. 19). In Maven Projekten ist es üblich, die Testmethoden, Testfälle und Testsuites im Quelltextverzeichnis src/test/java abzulegen und die Quelltexte im Quelltextverzeichnis src/main/java. Die Methode excludedpackagesfragmentroot(..) aus der Klasse EzServer bereitet an dieser Stelle Probleme. Sie wird aus der Methode newline(..) aufgerufen und ist in Listing 7 (Zeile 5) zu sehen. Um auszuschließen, dass Methoden aus dem Quelltextverzeichnis für Testfälle zu MUTs ausgewertet werden, wird hier überprüft, ob eine Methode in diesem Verzeichnis liegt. Der EzUnit Standardwert ist, wie in Abbildung 5 (S. 14) zu sehen, das Quelltextverzeichnis test. Die Methode excludedpackages- FragmentRoot(..) bezieht allerdings keine Unterverzeichnisse mit in die Überprüfung ein, so dass das Verzeichnis test/java nicht als von der MUT Ermittlung ausgeschlossen betrachtet wird. Um die Maven Paket-Struktur zu unterstützen, müsste eine durch eine geeignete Notation getrennte hierarchische Verzeichnisstruktur als Filter gesetzt werden, z.b. test/java oder test.java. Das Verzeichnis java an dieser Stelle anzugeben würde bei der Verwendung der Maven Paket-Struktur nicht ausreichen, da sich der Quelltext im Verzeichnis main/java befindet und somit auch die dort enthaltenen Methoden nicht als MUTs berücksichtigt werden würden. Zu beachten ist, dass die Überprüfung ob eine Methode in einem für Testfälle vorgesehen Quelltextverzeichnis liegt, für Testmethoden nicht durchgeführt wird (Zeilen 4-5). Die Testergebnisse für die JUnit 4 Projekte haben noch ein weiteres Problem aufgezeigt. Die ermittelte Anzahl Testmethoden von EzUnit im EzUnit Result View und JUnit stimmt nicht überein. Es gibt eine Differenz von 31 Testmethoden, die EzUnit gegenüber JUnit nicht als solche erkennt. In welchen Testklassen sich diese Methoden befinden ist in Tabelle 12 (S. 73) zu sehen. Aus dieser Auflistung ist ersichtlich, dass EzUnit die Testmethoden, die annotiert sind, nicht mit zu den Testmethoden zählt. Das ist in sofern korrekt, als dass diese auch von JUnit nicht ausgewertet werden. Die Abweichung der verbleibenden 28 Testmethoden lässt sich wie folgt erklären: EzUnit erhält die Angaben über die Anzahl der ausgeführten Testmethoden für den EzUnit Result View über den implementierten Test Run Listener (vgl. Abschnitt 2.4, S. 12). Es werden jedoch nicht alle so ermittelten Testmethoden für die Anzeige berücksichtigt, sondern zunächst die Methode testcaseelementtomethod(..) der Klasse org.projectory.ezunit.core.testmethod.testmethodstore aufgerufen. Diese versucht die Methode im Java Modell des Programms zu finden. Hierfür wird die von JDT bereitgestellte Methode JavaModelUtil.findMethodInHierarchy(..) verwendet. 31

40 Kann die Methode nicht ermittelt werden, wird sie nicht als Testmethode im EzUnit Result View berücksichtigt. Für nähere Informationen zu JDT sei an dieser Stelle auf die Projektseite verwiesen [JDT]. Als letzte Auffälligkeit ist das Verhalten von EzUnit bei den JUnit Projekten Spezialfall Assert auszuwerten. Das Problem, dass keine Matrixbildung durch EzUnit erfolgt, liegt darin begründet, dass durch die eingebauten Fehler in den Assert Klassen der Projekte die Testausführung von JUnit gestört wird. Bei der Ausführung von EzUnit kann man die durch das Tracing ermittelten Methodenaufrufe in der Konsole der IDE anzeigen lassen. Hierfür muss in der Datei trace.properties, die im Verzeichnis eclipse/ezunit der Eclipse Installation zu finden ist, die Eigenschaft ezconsole auf on gesetzt werden. Aus dem Tracing von EzJIP (vgl. Abschnitt 2.4, S. 12) wird ersichtlich, dass keine Testmethoden mehr durch JUnit aufgerufen werden. Obwohl JUnit eine Auflistung aller Testmethoden im JUnit View aufführt, und diese als fehlerhaft markiert, werden die Testfälle nicht ausgeführt. Der Fehler scheint demnach bereits vor der Ausführung der Testfälle zu passieren. Tatsächlich wird die fehlerhafte Klasse Assert für die Testausführung vom JUnit Framework genutzt. Die eingebundene JUnit Library im Klassenpfad der Testprojekte (vgl. Abschnitt 3.1, S. 19) wird nicht für die Testausführung genutzt, sondern JUnit führt einen reinen Selbsttest aus. Dies kann überprüft werden, indem die Library aus dem Klassenpfad entfernt wird. Das Ergebnis ist das gleiche. Die Anzahl der Testmethoden, die im EzUnit Result View als Failed tests und Passed tests angezeigt wird, erhält EzUnit, wie bereits erwähnt, direkt vom Test Run Listener. Die Matrix wird allerdings aus den Aufzeichnungen des Tracings gebildet. Dadurch, dass beim Tracing aber keine Testmethoden ermittelt werden können, kann EzUnit keine Matrix erstellen. 32

41 4 Umsetzung Um die in Abschnitt 3.3 erläuterten Probleme bei der Verwendung von JUnit als Testprojekt für EzUnit zu vermeiden, wird in diesem Kapitel ein Lösungsansatz vorgeschlagen. 4.1 Vorgehen Ziel dieser Bachelorarbeit ist es, eine Lösung zu erarbeiten, die es ermöglicht, JUnit als Testprojekt für EzUnit zu nutzen. Hierfür müssen die in Abschnitt 3.3 analysierten Probleme gelöst werden. Die drei Hauptursachen lassen sich wie folgt zusammenfassen: Filterfunktion Durch die Filterfunktionen von EzUnit werden zu viele Methoden von der Fehlerlokalisierung ausgeschlossen. Maven Paket-Struktur Durch die Verwendung der Maven Paket-Struktur kann keine klare Unterscheidung zwischen Codebasis (zu testender Quelltext) und Testbasis (Testfälle) getroffen werden. Selbsttest von JUnit Durch den reinen Selbsttest von JUnit (d.h. den Ausschluss der Nutzung einer externen Library zur Testausführung) wird die Arbeit von JUnit selbst gestört. Sobald Methoden, die zur Testausführung genutzt werden, selbst fehlerhaft sind, kann JUnit seine Arbeit nicht korrekt ausführen, was sich auch auf die Ergebnisse von EzUnit auswirkt. Die angeführten Gründe zeigen, dass die Problematik bei der Verwendung von JUnit als Testprojekt für EzUnit daraus resultiert, dass die angewandten Mechanismen zur Trennung zwischen Testprojekt und Testframework hier keine Gültigkeit haben. Daher wird vorgeschlagen, das JUnit Projekt zu refaktorisieren. Anstelle des Paketnamens junit soll im Folgenden refunit verwendet werden. Damit wird sowohl EzUnit als auch JUnit selbst eine klare Unterscheidung zwischen Testprojekt und Systemroutinen ermöglicht. Das Refactoring verhält sich dabei minimalinvasiv, so dass der Quelltext der JUnit Testprojekte nahezu unverändert bleibt. Desweiteren muss die Paket-Struktur der Testprojekte dahingehend verändert werden, dass die Testmethoden, Testfälle und Testsuites im Quelltextverzeichnis src/test liegen und nicht wie bisher im Quelltextverzeichnis src/test/java. Auch diese Änderung lässt sich über ein Refactoring lösen. Für die Testausführung mit EzUnit hat sich im Laufe der Tests mit den refaktorisierten Projekten herausgestellt, dass in EzUnit noch ein zusätzlicher Filter verwendet werden sollte. Da vom JUnit Framework auch Methoden aus dem Paket junit.runner zur Testausführung genutzt werden, wurde dieses Paket für die weiteren Untersuchungen zusätzlich in den Exclude Packages Filter (vgl. Abbildung 5, S. 14) von EzUnit übernommen. 33

42 Damit wird verhindert, dass Methoden aus diesem Paket als MUTs ausgewertet werden. Die so erweiterten Einträge dieses Filters für die folgenden EzUnit Durchläufe sind in Abbildung 7 zu sehen. Abbildung 7: Erweiterte Filterfunktion Exclude Packages für EzUnit Für die Umsetzung des Lösungsvorschlages wurden die sechs JUnit Testprojekte kopiert und die im Folgenden beschriebenen Änderungen vorgenommen. Die so entstandenen Projekte werden als RefUnit Testprojekte bezeichnet und entsprechend ihrer JUnit Vorlagen als RefUnit 3 ohne Fehler, RefUnit 4 ohne Fehler, allgemeiner Fehlerfall RefUnit 3, allgemeiner Fehlerfall RefUnit 4, Spezialfall Assert RefUnit 3 und Spezialfall Assert RefUnit 4 bezeichnet. Alle RefUnit Projekte befinden sich auf der beiliegenden CD (siehe Anhang B, S. 82) Refactoring der Paket-Struktur Um JUnit mit EzUnit testen zu können, muss die bisher verwendete Maven Paket- Struktur der RefUnit Projekte geändert werden. Die Projekte werden wie folgt refaktorisiert. Alle Tests werden über die in Eclipse integrierte Refactoring Funktion Move in das Verzeichnis src/test verschoben. Anschließend muss dieses Verzeichnis als Quelltextverzeichnis des Projektes angegeben werden. Das alte Quelltextverzeichnis src/test/java kann in den Projekteigenschaften als Quelltextverzeichnis entfernt und das Verzeichnis java gelöscht werden Refactoring der Paketnamen Für das Refactoring der Paketnamen werden in den sechs RefUnit Projekten alle Pakete mit dem Namen junit in refunit umbenannt. So wird beispielsweise aus dem Paket org.junit das Paket org.refunit. Das Refactoring der Paketnamen wird sowohl für die Quelltexte als auch für die Testfälle der Projekte durchgeführt. Hierfür wird die in Eclipse eingebundene Rename-Funktion für das automatisierte Refactoring auf Paketebene benutzt. Wichtig ist dabei, dass sowohl die Option Update references als auch Rename subpackages ausgewählt ist (siehe Abbildung 8). 34

43 Damit erfolgt ein automatisches Update der im Projekt vorhandenen Referenzen auf die umbenannten Pakete und auch alle hierarchisch untergeordneten Pakete werden vom Refactoring eingeschlossen. Abbildung 8: Eingabemaske für die Eclipse Rename-Funktion auf dem Paket org.junit Die Rename-Funktion ist im Falle der RefUnit 3 Projekte auf dem Paket junit sowohl im Quelltextverzeichnis src/main/java, in dem die Quelltexte liegen, als auch im Quelltextverzeichnis src/test, in dem die Testfälle liegen, anzuwenden. Im Falle der RefUnit 4 Projekte muss das Refactoring zusätzlich noch auf dem Paket org.junit der Verzeichnisse src/main/java und src/test ausgeführt werden. Exemplarisch ist in Abbildung 9 die refaktorisierte Paket-Struktur des Projektes RefUnit 4 ohne Fehler abgebildet. Abbildung 9: Paket-Struktur RefUnit 4 ohne Fehler Durch die Funktion Update references werden beim Refactoring alle Verweise auf refaktorisierte Quelltexte automatisch aktualisiert. Das bedeutet in diesem Fall, dass alle Testsuites, Testklassen und Testmethoden jetzt nicht mehr vom JUnit Framework als solche erkannt werden. So haben beispielsweise die Testklassen der RefUnit 3 Projekte nicht mehr die Superklasse junit.framework.testcase sondern refunit.framework. TestCase. Gleiches gilt für die Testmethoden der RefUnit 4 Projekte; sie sind nicht 35

44 länger mit der Annotation org.junit.test versehen, sondern mit org.refunit.test. Diese Testklassen und Testmethoden kann das JUnit Framework nicht ausführen. Um die Testfälle weiterhin mit dem JUnit Framework ausführen zu können, müssen die entsprechenden Klassen manuell nachbearbeitet werden. Alle ausführbaren Testklassen müssen im Falle der RefUnit 3 Projekte von junit.framework.testcase erben und im Fall der Testprojekte RefUnit 4 müssen alle Testmethoden mit einer entsprechenden JUnit-Annotation markiert sein (org.junit.test oder org.junit.theory). Auch die Auswertung der Ergebnisse innerhalb der Testmethoden durch die Assert Methoden muss entsprechend geändert werden, denn nur die vom JUnit Framework bereitgestellten Methoden können für die Testausführung ausgewertet werden. Dadurch, dass die RefUnit Projekte Kopien der JUnit Projekte sind, werden die in den Klassenpfad eingebundenen externen Bibliotheken ebenfalls kopiert und liefern die entsprechenden Klassen und Methoden für die beschriebenen Anpassungen. Einen Auszug aus einem entsprechend überarbeiteten Testfall eines RefUnit 3 Projektes zeigen die Listings 8, 9 und package r e f u n i t. t e s t s. framework ; 2 3 import j u n i t. framework. Assert ; 4 import r e f u n i t. framework. TestSuite ; 5 6 public class SuiteTest extends j u n i t. framework. TestCase { 7 8 protected r e f u n i t. framework. TestResult f R e s u l t ; 9 10 public SuiteTest ( S t r i n g name) { 11 super (name) ; 12 } protected void setup ( ) { 15 f R e s u l t= new r e f u n i t. framework. TestResult ( ) ; 16 } // Fortsetzung s i e h e L i s t i n g 10 Listing 8: Auszug eines RefUnit 3 Testfalls Teil 1 Die Testklasse SuiteTest muss eine Subklasse von junit.framework.testcase sein, um als Testfall vom JUnit Framework erkannt und ausgeführt zu werden (siehe Listing 8). Entsprechend ist auch die überschriebenen Test Fixture setup() von dieser Klasse. 36

45 1 // Fortsetzung von L i s t i n g public static j u n i t. framework. Test s u i t e ( ) { 4 j u n i t. framework. TestSuite s u i t e = new j u n i t. framework. TestSuite ( S u i t e Tests ) ; s u i t e. addtest (new SuiteTest ( t e s t I n h e r i t e d T e s t s ) ) ; return s u i t e ; 9 } / 12 Diese Testmethode t e s t e t das Verhalten der Klasse 13 r e f u n i t. framework. TestSuite, i s t aber e i n JUnit T e s t f a l l. 14 / 15 public void t e s t I n h e r i t e d T e s t s ( ) { r e f u n i t. framework. TestSuite s u i t e= new r e f u n i t. framework. TestSuite ( InheritedTestCase. class ) ; s u i t e. run ( f R e s u l t ) ; j u n i t. framework. Assert. asserttrue ( f R e s u l t. w a s S u c c e s s f u l ( ) ) ; 22 j u n i t. framework. Assert. a s s e r t E q u a l s ( 2, f R e s u l t. runcount ( ) ) ; 23 } // Fortsetzung s i e h e L i s t i n g } Listing 9: Auszug eines RefUnit 3 Testfalls Teil 2 Die Methode suite() (siehe Listing 9) wird vom Referenztestfall refunit.tests.all- Tests (vgl. Abschnitt 3.1.1, S. 20) aufgerufen, der eine JUnit TestSuite ist, und daher ein Objekt erwartet, welches das Interface junit.framework.test implementiert. Ihr wird die Testmethode testinheritedtests() der Klasse SuiteTest übergeben. Die Testmethode allerdings testet nun den Quelltext des RefUnit Projektes, indem eine RefUnit Testsuite erzeugt wird, der wiederum ein Objekt der Superklasse refunit. framework.testcase übergeben wird. Das zugehörige TestResult ist ebenfalls eine Instanz der Klasse refunit.framework.testresult und wird in der JUnit Test Fixture (Zeile 15 Listing 8) der Klasse SuiteTest erzeugt. Es steht somit dem Testfall testinheritedtest() zur Verfügung. Die Assert Methoden des Testfalls sind wiederum von der Klasse junit.framework.assert. Sonst wären sie vom JUnit Framework nicht auswertbar. 37

46 Um die gleichen Testergebnisse zu erzielen wie vor dem Refactoring, müssen noch einige Anpassungen an den RefUnit Projekten vorgenommen werden. Einige Testfälle müssen dupliziert werden, da sie nun sowohl für die Ausführung als JUnit Tests, als auch für die Tests der RefUnit Codebasis benötigt werden. Exemplarisch sei hier die bereits in den Listings 8 und 9 vorgestellte Testklasse SuiteTest herausgegriffen. Ein Auszug der Testklasse aus einem der JUnit 3 Projekte ist in Listing 10 zu sehen public void testnotexistingtestcase ( ) { 3 Test t= new SuiteTest ( notexistingmethod ) ; // j u n i t. framework. Test 4 t. run ( f R e s u l t ) ; // j u n i t. framework. TestResult 5 asserttrue ( f R e s u l t. runcount ( ) == 1) ; // j u n i t. framework. Assert 6 asserttrue ( f R e s u l t. f a i l u r e C o u n t ( ) == 1) ; // j u n i t. framework. Assert 7 asserttrue ( f R e s u l t. errorcount ( ) == 0) ; // j u n i t. framework. Assert 8 } 9... Listing 10: Auszug der Testklasse SuiteTest aus einem JUnit 3 Projekt Die Testmethode testnotexistingtestcase() initiiert einen neuen Test, indem sie die Testmethode notexistingmethod() aufruft (Zeile 3). Im RefUnit 3 Projekt sind das Interface Test und die Klasse TestResult allerdings aus dem RefUnit Projekt und können somit nicht die Klasse SuiteTest verarbeiten, die ja eine Subklasse von junit. framework.testcase ist (vgl. Listing 8). Um den Testfall testnotexistingtestcase() dennoch weiterhin sinngemäß ausführen zu können, wurde für die RefUnit Projekte je eine Kopie der Klasse SuiteTest mit Namen SuiteTest2 erstellt, die eine Subklasse von refunit.framework.testcase ist (vgl. Listing 11). 1 // Fortsetzung von L i s t i n g public void testnotexistingtestcase ( ) { 4 r e f u n i t. framework. Test t= new SuiteTest2 ( notexistingmethod ) ; 5 t. run ( f R e s u l t ) ; // r e f u n i t. framework. TestResult 6 j u n i t. framework. Assert. asserttrue ( f R e s u l t. runcount ( ) == 1) ; 7 j u n i t. framework. Assert. asserttrue ( f R e s u l t. f a i l u r e C o u n t ( ) == 1) ; 8 j u n i t. framework. Assert. asserttrue ( f R e s u l t. errorcount ( ) == 0) ; 9 } Listing 11: Auszug eines RefUnit 3 Testfalls Teil 3 Neben der Notwendigkeit, von einigen Testklassen Duplikate anzulegen, gibt es einige Testklassen und Quelltextklassen, die angepasst werden müssen, weil sie Strings enthalten, mit denen der Klassenpfad von Ressourcen angegeben wird. Da sich die Paket- 38

47 Struktur geändert hat, können diese Ressourcen nicht mehr aufgefunden werden, wenn die entsprechenden Strings nicht geändert werden. Ein Beispiel zeigt Listing public c l a s s TextRunnerTest extends TestCase { 3 4 public void t e s t F a i l u r e ( ) throws Exception { 5 exectest ( r e f u n i t. t e s t s. framework. F a i l u r e, f a l s e ) ; 6 } 7... Listing 12: Auszug eines RefUnit 3 Testfalls mit geänderter Paket-Struktur Die Pfadangabe in der Testklasse refunit.tests.runner.textrunnertest wurde von junit.tests.framework.failure in refunit.tests.framework.failure geändert (siehe Zeile 5). Für die RefUnit 4 Projekte müssen auf Grund der neuen Sprachkonstrukte von JUnit in der Vesion 4 (vgl. Abschnitt 2.3.2, S. 9) noch zusätzlich die folgenden Anpassungen vorgenommen werden: Alle Testfälle, die Theorien verwenden, müssen noch einmal überarbeitet werden. Soll das Verhalten von Theorien getestet werden, müssen diese nun aus den Paketen der RefUnit Projekte stammen. Ist dies der Fall, so werden die Theorien aber nicht mehr vom JUnit Framework als Testfälle erkannt. Um diese Tests dennoch ausführen zu können, wurden Testmethoden zur Testbasis hinzugefügt, die die Ausführung der RefUnit Theorien ermöglichen. Für jede Theorie wurde eine JUnit Testmethode hinzugefügt, die die Theorie ausführt. Dasselbe gilt für parametrisierte Tests. Ein Beispiel zeigt Listing 13. Die ursprüngliche JUnit Theorie ParameterSignatureTest wurde für die Ausführung in eine innere Klasse ParameterSignatureInnerTest gekapselt, welche ausschließlich Klassen und Methoden aus dem RefUnit Projekt enthält. Die Testmethode gettypetheory() wurde der Testklasse ParameterSignatureTest hinzugefügt und kann vom JUnit Framework ausgeführt werden, da sie eine JUnit Testmethode ist. Über die RefUnit Klasse JUnitCore, kann die Theorie nun ausgeführt und mit Hilfe der JUnit Assert Methoden das Testergebnis in Form der Klasse Result (aus dem RefUnit Quelltext) überprüft werden. So wird es für das JUnit Framework auswertbar (vgl. Zeilen 28-31). 39

48 1 public class ParameterSignatureTest { 2 Theories. class ) 4 public static class ParameterSignatureInnerTest { 5 7 public static Method gettype ( ) throws SecurityException, 8 NoSuchMethodException { 9 return ParameterSignatureInnerTest. class. getmethod ( gettype, Method. class, int. class ) ; 10 } public static int ZERO= 0 ; public static int ONE= 1 ; public void gettype ( Method method, int i n d e x ) { 20 assumetrue ( index < method. getparametertypes ( ). length ) ; 21 a s s e r t E q u a l s ( method. getparametertypes ( ) [ index ], ParameterSignature 22. s i g n a t u r e s ( method ). get ( index ). gettype ( ) ) ; 23 } 24 } public void gettypetheory ( ) { 28 Result r e s u l t = JUnitCore. runclasses ( ParameterSignatureInnerTest. class ) ; 29 org. j u n i t. Assert. assertthat ( r e s u l t. getruncount ( ), i s ( 1 ) ) ; 30 org. j u n i t. Assert. assertthat ( r e s u l t. getignorecount ( ), i s ( 0 ) ) ; 31 org. j u n i t. Assert. assertthat ( r e s u l t. getfailurecount ( ), i s ( 0 ) ) ; 32 } } Listing 13: Beispiel eines RefUnit 4 Testfalls mit Theorien Für die Anpassungen von parametrisierten Tests ist noch zu beachten, dass das Ergebnis im JUnit View hierdurch verändert wird. Ein parametrisierter Test wird normalerweise vom JUnit Framework nicht als ein Run gezählt, sondern es wird, wie bereits in Abschnitt (S. 9) beschrieben, jede Parameterausprägung als Run gezählt. Wird nun eine parametrisierte Testmethode zur Ausführung gebracht, wird vom Junit Framework nur die Testmethode als Run gezählt, die die parametriesierte Testmethode des RefUnit Projektes ausführt. 40

49 Daher ergibt sich bei einem Durchlauf der Testsuites aus den RefUnit 4 Projekten eine Abweichung zur Anzahl Runs der JUnit 4 Projekte. Für die JUnit 4 Projekte ermittelt das JUnit Framework 582 Runs 8, für die RefUnit 4 Projekte lediglich 580 Runs 8. Eine Auflistung aller bearbeiteten Klassen der RefUnit Projekte findet sich im Anhang. Tabelle 14 (S. 74) zeigt die veränderten Klassen der RefUnit 3 Projekte und Tabelle 15 (S. 76) die der RefUnit 4 Projekte. 4.2 Ergebnisse Im Folgenden soll das Ergebnis des umgesetzten Lösungsvorschlags überprüft werden. Hierfür werden die sechs RefUnit Projekte mit EzUnit ausgeführt. Die erwarteten Ergebnisse sind die bereits in Abschnitt 3.2 (S. 25) vorgestellten. Die Ergebnisse werden in den nächsten Abschnitten im Detail beschrieben. Eine Auswertung der Ergebnisse wird anschließend in Abschnitt 5 (S. 46) vorgenommen. Von allen beschriebenen Testergebnissen befindet sich je ein Screenshot auf der beiliegenden CD und auch die Logausgaben zu allen EzUnit Durchläufen sind dort zu finden (siehe Anhang B, S. 82) Testprojekt RefUnit 3 ohne Fehler Beim Testprojekt RefUnit 3 ohne Fehler handelt es sich wie bereits beschrieben, um die refaktorisierte Kopie des JUnit 3 Projektes. Neben den bereits in Abschnitt (S. 26) genannten erwarteten Ergebnissen wird vom Testprojekt RefUnit 3 ohne Fehler insbesondere angenommen, dass alle 103 Testfälle auch im EzUnit Matrix View angezeigt werden und auch alle im EzUnit Result View ermittelten MUTs in die Matrix des EzUnit Matrix Views einbezogen werden. Außerdem wird erwartet, dass sich unter den MUTs keine Testmethoden mehr befinden. Tabelle 6: Ergebnisse Testprojekt RefUnit 3 ohne Fehler JUnit EzUnit Result View Result View Matrix View Runs Errors Failures MUTs Failed Passed MUTs Testfälle davon je (3 ignored) 41

50 Wie in Tabelle 6 zu sehen ist, sind immer noch zu wenig Testmethoden im EzUnit Matrix View vorhanden. Von den 103 erwarteten Testmethoden werden lediglich 97 berücksichtigt. Nicht berücksichtigt wurden dabei die im folgenden aufgelisteten Testmethoden: refunit.tests.framework.noargtestcasetest.testnothing() refunit.tests.framework.testcasetest.testcasetostring() refunit.tests.runner.sortertest.testsort() refunit.tests.runner.textrunnertest.testfailure() refunit.tests.runner.textrunnertest.testsuccess() refunit.tests.runner.textrunnertest.testerror() Auch von den 156 ermittelten MUTs werden im EzUnit Matrix View nur 155 angezeigt. Eine MUT fehlt bei der Matrixbildung. Dabei handelt es sich um die Methode refunit.extensions.activetestsuite.runfinished(). Aus den Logausgaben ist ersichtlich, dass die Methode beim Erstellen des EzUnit Result Views als MUT erfasst wird, im EzUnit Matrix View dagegen nicht. Ansonsten entspricht das Ergebnis den Erwartungen. Insbesondere ist zu sehen, dass unter den Ergebnissen nun auch Testmethoden und MUTs aus dem Paket refunit. framework zu finden sind (dies entspricht dem Paket junit.framework aus dem Testprojekt JUnit 3 ohne Fehler) Testprojekt RefUnit 4 ohne Fehler Beim Testprojekt RefUnit 4 ohne Fehler handelt es sich um eine refaktorisierte Kopie des Projektes JUnit 4 ohne Fehler. Die Erwartung an das Ergebnis des Testprojektes ist identisch mit den im vorigen Abschnitt beschriebenen Erwartungen an das Projekt Ref- Unit 3 ohne Fehler. Insbesondere wird beim Projekt RefUnit 4 ohne Fehler angenommen, dass die ermittelte Testfallanzahl von JUnit und EzUnit übereinstimmt und dass die Methoden und Testfälle der beiden Pakete refunit.framework und org.refunit in die Matrixbildung des EzUnit Matrix Views einbezogen werden. Tabelle 7: Ergebnisse Testprojekt RefUnit 4 ohne Fehler JUnit EzUnit Result View Result View Matrix View Runs Errors Failures MUTs Failed Passed MUTs Testfälle 580 (3 ignored) Tabelle 7 zeigt, dass die Anzahl der Testmethoden, die für die Anzeige im EzUnit Result View ermittelt wurden, auch nach dem Refactoring nicht mit der Anzahl der ausgeführten Testmethoden übereinstimmt, die EzUnit für die Matrixbildung im EzUnit Matrix 42

51 View verwendet. Es ergibt sich eine Differenz von sieben Testmethoden, die nachfolgend aufgelistet sind: refunit.tests.framework.testcasetest.testcasetostring() refunit.tests.runner.textrunnertest.testfailure() refunit.tests.framework.noargtestcasetest.testnothing() refunit.tests.runner.textrunnertest.testsuccess() refunit.tests.runner.textrunnertest.testerror() org.refunit.tests.running.core.systemexittest.failurecausesexitcodeof1() org.junit.tests.description.annotateddescriptiontest. characterizecreatingmyownannotation() Auch von den ermittelten MUTs werden sieben nicht bei der Matrixbildung berücksichtigt. Dabei handelt es sich um die folgenden Methoden: refunit.extensions.activetestsuite.runfinished() org.refunit.runner.notification.runnotifier.pleasestop() org.refunit.experimental.results.failurelist(list<failure>) org.refunit.experimental.results.failurelist.result() org.refunit.experimental.max.maxhistory(file) org.refunit.experimental.results.printableresult(list<failure>) org.refunit.internal.runners.statements.failontimeout.statementthread. run() Darüber hinaus kann festgestellt werden, dass die im EzUnit Result View ermittelte Anzahl an Testmethoden von EzUnit nicht mit der Anzahl übereinstimmt, die JUnit ermittelt hat. Es ergibt sich eine Differenz von 13 Testmethoden. Eine Auflistung der betroffenen Testklassen findet sich in Tabelle 13 (S. 74). Eine Erklärung hierfür wurde bereits in Abschnitt 3.3, S. 30 gegeben. Positiv hervorgehoben werden kann auch bei den Ergebnissen dieses Projektes, dass die Pakete refunit.framework und org.refunit diesmal nicht von der Matrixbildung im EzUnit Matrix View ausgeschlossen wurden. 43

52 4.2.3 Testprojekt RefUnit 3 mit injizierten Fehlern Beim Testprojekt RefUnit 3 mit injizierten Fehlern handelt es sich um die beiden Projekte allgemeiner Fehlerfall RefUnit 3 und Spezialfall Assert RefUnit 3. Sie sind Kopien der Testprojekte allgemeiner Fehlerfall JUnit 3 und Spezialfall Assert JUnit 3. Die erwarteten Ergebnisse entsprechen den bereits in Abschnitt (S. 27) beschriebenen. Insbesondere für das Projekt Spezialfall Assert RefUnit 3 wird darüber hinaus eine Ergebnisdarstellung in beiden Views von EzUnit angenommen. Für beide Projekte wird darüber hinaus erwartet, dass alle mit Fehlern injizierten Methoden bei den verdächtigen MUTs im EzUnit Result View berücksichtigt werden. Tabelle 8 fasst die vorgefundenen Ergebnisse zusammen. Tabelle 8: Ergebnisse Testprojekt RefUnit 3 mit injizierten Fehlern JUnit EzUnit injizierte Result View Result View Matrix View Fehler Runs Errors Failures MUTs Failed Passed MUTs Testfälle vier eins Sofort ersichtlich ist, dass beim Testprojekt Spezialfall Assert RefUnit 3 sowohl im Ez- Unit Matrix View als auch im EzUnit Result View ein Ergebnis angezeigt wird. Außerdem werden bei beiden Projekten alle injizierten Fehler von EzUnit lokalisiert und die entsprechenden MUTs mit einem Verdächtigkeitswert angegeben. Ansonsten entspricht das Ergebnis weitestgehend dem in Abschnitt (S. 41) beschriebenen: Auch beim Testprojekt RefUnit 3 mit injizierten Fehlern werden von den 103 Testfällen, die JUnit ermittelt, nur 97 im jeweiligen EzUnit Matrix View angezeigt. Eine Auflistung der betroffenen Testfälle wurde bereits vorgenommen. Ebenfalls beobachtet werden kann, dass die berechnete Anzahl MUTs im EzUnit Result View nicht mit der im EzUnit Matrix View ermittelten Anzahl MUTs übereinstimmt. Auch die ermittelte Anzahl MUTs der verschiedenen Testprojekte stimmt nicht überein. Im Testprojekt RefUnit 3 ohne Fehler und im Testprojekt Spezialfall Assert RefUnit 3 sind es 156, im Testprojekt allgemeiner Fehlerfall RefUnit 3 wurden dagegen nur 153 MUTs berechnet. Die korrespondierende Anzahl der tatsächlich verwendeten MUTs für die Matrixbildung der drei Projekte bleibt allerdings im Verhältnis konstant. Es ergibt sich jeweils ein Unterschied von einer MUT, die nicht in die Matrix im EzUnit Matrix View einbezogen wird. Dabei handelt es sich in allen Projekten um die bereits in Abschnitt (S. 41) erwähnte Methode refunit.extensions.activetestsuite. runfinished(). 9 Testprojekt allgemeiner Fehlerfall RefUnit 3 10 Testprojekt Spezialfall Assert RefUnit 3 44

53 4.2.4 Testprojekt RefUnit 4 mit injizierten Fehlern Beim Testprojekt RefUnit 4 mit injizierten Fehlern handelt es sich um die beiden Projekte allgemeiner Fehlerfall RefUnit 4 und Spezialfall Assert RefUnit 4. Diese sind Kopien der Projekte allgemeiner Fehlerfall JUnit 4 und Spezialfall Assert JUnit 4, auf denen die in Abschnitt 4.1 (S. 33) beschriebenen Refactorings ausgeführt wurden. Tabelle 9 beschreibt die vorgefundenen Ergebnisse. Die Erwartungshaltung ist identisch mit der in Abschnitt (S. 42) beschriebenen. Auch hier gilt für das Testprojekt Spezialfall Assert RefUnit 4 im Besonderen, dass ein Ergebnis in den EzUnit Views angenommen wird. Außerdem wird erwartet, dass alle injizierten Fehler von EzUnit lokalisiert und mit einem entsprechenden Verdächtigkeitswert ausgezeichnet werden. Tabelle 9: Ergebnisse Testprojekt RefUnit 4 mit injizierten Fehlern JUnit EzUnit injizierte Result View Result View Matrix View Fehler Runs 13 Errors Failures MUTs Failed Passed MUTs Testfälle vier eins Aus Tabelle 9 ist ersichtlich, dass beim Testprojekt Spezialfall Assert RefUnit 4 Ergebnisse in den EzUnit Views dargestellt werden. Zudem wurden bei beiden Testläufen alle Methoden mit injizierten Fehlern im EzUnit Result View lokalisiert. Wie bereits in Abschnitt (S. 42) beschrieben, lassen sich aber dennoch einige Unstimmigkeiten im Ergebnis von EzUnit beobachten. Die Anzahl der ermittelten MUTs im EzUnit Result View und im EzUnit Matrix View stimmen nicht überein und auch die Anzahl der verwendeten Testmethoden ist nicht identisch. Außerdem ist die Anzahl der Testmethoden, die von JUnit ermittelt wurden, nicht identisch mit der von EzUnit ermittelten Anzahl. Die jeweils sieben Testmethoden und sieben MUTs, die im EzUnit Result View enthalten sind, im EzUnit Matrix View aber nicht, sind identisch mit den in Abschnitt (S. 42) genannten. Gleiches gilt für die 13 Testmethoden die EzUnit gegenüber JUnit zu wenig ermittelt (vgl. hierzu Tabelle 13, S. 74). Zu beobachten ist auch, dass die Anzahl der ermittelten MUTs der verschiedenen Ref- Unit 4 Testprojekte nicht übereinstimmt. Bei den Testprojekten allgemeiner Fehlerfall RefUnit 4 und RefUnit 4 ohne Fehler wurden jeweils 800 MUTs ermittelt, beim Testprojekt Spezialfall Assert RefUnit 4 dagegen 806. Diese Feststellung konnte bereits für die RefUnit 3 Projekte beobachtet werden. 11 Testprojekt allgemeiner Fehlerfall RefUnit 4 12 Testprojekt Spezialfall Assert RefUnit 4 13 davon je (3 ignored) vgl. hierzu Tabelle 7, S

54 5 Evaluierung Die im vorigen Abschnitt beschriebenen Ergebnisse der Testläufe von EzUnit auf den refaktorisierten JUnit Projekten sollen in diesem Abschnitt evaluiert werden. Obwohl es wesentliche Verbesserungen im Testergebnis gab, sind doch noch einige Unstimmigkeiten gegenüber den erwarteten Ergebnissen aufgetreten. Um die beobachteten Ergebnisse und die Eignung des Lösungsansatzes zu bewerten, wird hier eine Methode zur Evaluierung der Ergebnisse vorgestellt. Die Idee zur Evaluierung basiert auf den in Abschnitt 2.4 (S. 12) beschriebenen Grundlagen des EzUnit Frameworks. EzUnit erstellt als grundlegende Eingabe für Berechnungen zur Fehlerlokalisierung eine Matrix, die aus den Testmethoden und den aufgerufenen MUTs besteht. Die Idee zur Evaluierung besteht darin, nachzuweisen, dass alle durchlaufenen Testmethoden und die dadurch aufgerufenen MUTs in der von EzUnit erstellten Matrix berücksichtigt werden. Ist dies der Fall, wird davon ausgegangen, dass auch die darauf ausgeführten Berechnungen zur Fehlerlokalisierung korrekt sind. Diese Annahme wird damit begründet, dass bei JUnit als Testprojekt in der Analyse beobachtet werden konnte, dass genau diese Eingangsparameter zur Fehlerberechnung nicht korrekt waren (vgl. Abschnitt 3.3, S. 30). Sowohl Testmethoden als auch MUTs wurden nicht oder nicht richtig erkannt, was dazu führte, dass die Matrix unvollständig war und somit auch die darauf ausgeführte Fehlerlokalisierung nicht korrekt ausgeführt werden konnte. Durch die Anwendung des in Abschnitt 4.1 (S. 33) vorgestellten Lösungsansatzes wird nun erwartet, dass die von EzUnit gebildete Matrix vollständig ist und damit korrekte Ergebnisse bei der Fehlerlokalisierung erzielt werden. Um dies zu prüfen, wurde ein Aspekt in AspectJ implementiert, der ermitteln soll, welche Testmethoden bei einem JUnit Testlauf aufgerufen werden und welche Methoden im Quelltext des Testprojektes wiederum von den Testmethoden aufgerufen werden. Diese Quelltextmethoden entsprechen den MUTs in EzUnit. Ein Abgleich der Ergebnisse mit den von EzUnit verwendeten Methoden für die Matrixbildung soll die Vollständigkeit der verwendeten Eingaben für die Fehlerlokalisierung nachweisen. Die Grundlagen zu AspectJ, sowie die vollständige Implementierung zur Evaluierung des Lösungsvorschlages, werden in den folgenden Unterabschnitten beschrieben. Abschließend werden die Ergebnisse aus Abschnitt 4.2 (S. 41) ausgewertet. 5.1 Grundlagen AspectJ Im Folgenden wird eine kurze Einführung in AspectJ gegeben, die sich auf die für diese Arbeit relevanten Teile beschränkt und lediglich zum Verständnis der beschriebenen Implementierung dienen soll. 46

55 Um die Evaluierung des in Abschnitt 4.1 (S. 33) beschriebenen Lösungsansatzes zu ermöglichen, musste ein Ansatz gefunden werden, der es mit minimalem Aufwand erlaubt, einen JUnit Testlauf auf einem Testprojekt beobachten zu können. Hierfür eignet sich insbesondere die aspektorientierte Programmierung, da weder eine Manipulation des Testprojektes noch des Testframeworks erforderlich ist um die benötigten Daten für die Evaluierung zu ermitteln. Da sowohl das Testframework als auch das Testprojekt in Java implementiert sind, bietet AspectJ eine einfache und effiziente Methode der Implementierung. Wie in [Boe06] beschrieben, lassen sich mit Hilfe von AspectJ programmübergreifende Themen (sog. Crosscutting Concerns) an einer zentralen Stelle verwalten. Das Ermitteln der Methodenaufrufe eines Testlaufs stellt einen solchen Crosscutting Concern dar. Ohne die Methoden zu ändern, kann mit Hilfe eines Aspektes genau definiert werden, welche Methoden beobachtet werden sollen und zu welchem Zeitpunkt. AspectJ bietet hierfür die folgenden Sprachkonstrukte an: Joinpoint Ein Joinpoint stellt einen Punkt im Programmlauf dar, an dem eine bestimmte Funktionalität (in Form eines Advice) ausgeführt werden soll, z.b. der Aufruf einer Methode. Advice Ein Advice beschreibt die Funktionalität, die an einer durch einen Joinpoint definierten Stelle ausgeführt werden soll. Man unterscheidet dabei die folgenden Advice-Typen: Before-, After- und Around-Advice. Ein Before-Advice wird vor einem Joinpoint ausgeführt, ein After-Advice nach einem Joinpoint, und ein Around- Advice anstelle eines Joinpoints. Pointcut Ein Pointcut beschreibt schließlich eine Menge von Joinpoints, an denen ein bestimmter Advice ausgeführt werden soll. Im nächsten Abschnitt wird die Implementierung für die Evaluierung beschrieben und die dafür verwendeten Sprachkonstrukte noch einmal im Detail erläutert. An dieser Stelle sei noch auf die Umgebung hingewiesen, in der AspectJ verwendet werden kann. Um die beschriebenen Sprachkonstrukte zur Anwendung zu bringen, wird ein AspectJ-Compiler benötigt. Dieser injiziert den Aspekt direkt in den Java-Bytecode eines Java Projektes (im vorliegenden Fall den Bytecode der refaktorisierten Testprojekte). Man spricht hierbei vom sogenannten Weaving (engl. für Weben). Der Advice-Code wird hierdurch an die entsprechenden Stellen (Joinpoints) im Bytecode geschrieben und zur Laufzeit mit ausgeführt. Eclipse unterstützt die Erstellung von Aspekten durch das Bereitstellen von entsprechenden Plug-ins. Für diese Arbeit wurde das AspectJ Development Tools (AJDT) Plug-in verwendet, das über den Eclipse Marketplace installiert werden kann. Es ermöglicht die einfache Konvertierung von Java Projekten in AspectJ Projekte, wodurch das Weaving direkt in der IDE erfolgt, ohne dass der AspcetJ-Compiler separat aufgerufen werden muss. Für mehr Informationen zu AJDT siehe [AJDT]. 47

56 5.2 Implementierung Für die Evaluierung des Lösungsvorschlages aus Abschnitt 4.1 (S. 33) wurden insgesamt zwei Komponenten entwickelt. Zum einen der Aspekt Taspect und zum anderen der EzUnitComparator. Taspect wurde in AspectJ implementiert. Der Aspekt integriert sich in den Bytecode eines Testprojektes und schreibt eine Logdatei, die bei einem JUnit Durchlauf ausgibt, welche Testmethoden ausgeführt wurden und welche MUTs durch die Testmethoden aufgerufen wurden. Beim EzUnitComparator handelt es sich um ein Java-Programm, welches den Vergleich der verschiedenen im EzUnit Projekt implementierten Logausgaben und den Logausgaben des Aspektes Taspect ermöglicht. Die beiden Komponenten werden in den nächsten Abschnitten vorgestellt Taspect Der Aspekt Taspect wurde implementiert, um die Aufrufe von JUnit Tests zu beobachten, ähnlich wie EzJIP dies für EzUnit macht (vgl. hierzu Abschnitt 2.4, S. 12). Hierfür wurden drei Pointcuts implementiert (siehe Listing 14), die als Joinpoints alle Testmethoden zur Ausführungszeit adressieren. Einer der Pointcuts bezieht sich dabei auf die Testmethoden von JUnit 3 Tests, die das Namenspräfix test tragen und in Subklassen von junit.framework.testcase enthalten sind. Die beiden anderen Pointcuts beziehen sich auf die Testmethoden von JUnit 4 Tests, die entweder Test oder annotiert sind. 1 // t e s t method JUnit 3 s t y l e 2 public pointcut t e s t S n i f f e r ( ) : 3 execution ( void j u n i t. framework. TestCase +. t e s t ( ) ) ; 4 5 // t e s t method JUnit 4 s t y l e 6 public pointcut a n n o t a t e d T e s t S n i f f e r ( ) : 7 execution j u n i t. Test ( ) ) ; 8 9 // theory ( JUnit 4) 10 public pointcut t h e o r y S n i f f e r ( ) : 11 execution j u n i t. experimental. t h e o r i e s. Theory (.. ) ) ; Listing 14: Pointcuts die Joinpoints zur Ausführung der Testmethoden beschreiben Der Pointcut testsniffer() (vgl. Zeilen 2-3) adressiert die Ausführung (execution) aller Methoden der Subklassen von TestCase (TestCase+), deren Name mit dem Präfix test (test*()) beginnt. Der Pointcut annotatedtestsniffer() (vgl. Zeilen 6-7) adressiert die Ausführung aller Methoden, die mit der versehen sind (@org. junit.test**()). Der Pointcut theorysniffer() (vgl. Zeilen 10-11) adressiert die Ausführung aller Methoden, die JUnit Theorien sind. Zu beachten ist hierbei, dass 48

57 JUnit Theorien Übergabeparameter haben können. Der Methodenaufruf ist entsprechend definiert Nähere Informationen zur Definition von Pointcuts finden sich in [Boe06], S. 75ff. Für die drei beschriebenen Pointcuts wurde jeweils ein Before-Advice implementiert, der vor jedem adressierten Joinpoint ausgeführt wird. Listing 15 zeigt zwei dieser Advices. Der Before-Advice für den Pointcut annotatedtestsniffer() entspricht dem für den Pointcut testsniffer() und ist nicht mit in Listing 15 aufgeführt. 1 before ( ) : t e s t S n i f f e r ( ) { 2 this. currenttestmethod = 3 thisjoinpointstaticpart. g e t S i g n a t u r e ( ). t o S t r i n g ( ) ; 4 writetestmethodlogentry ( t h i s. currenttestmethod ) ; 5 } 6 7 before ( ) : t h e o r y S n i f f e r ( ) { 8 this. currenttestmethod = 9 thisjoinpointstaticpart. g e t S i g n a t u r e ( ). t o S t r i n g ( ) ; 10 i f (! theoryset. c o n t a i n s ( this. currenttestmethod ) ) { 11 theoryset. add ( this. currenttestmethod ) ; 12 writetestmethodlogentry ( t h i s. currenttestmethod ) ; 13 } 14 } Listing 15: Before-Advices für die Pointcuts aus Listing 14 Der grundlegende Aufbau eines Before-Advice folgt dabei der folgenden Syntax: before(): Pointcut { Body } In Listing 15 ist zu sehen, dass für jeden Joinpoint, der durch den Pointcut testsniffer() beschrieben wird, die Methode writetestmethodlogentry(..) (siehe Zeile 4) aufgerufen wird. Diese inkrementiert einen Zähler und schreibt einen Logeintrag für die entsprechende Testmethode. Das Logging wird dabei mit Log4j realisiert (Informationen zu Log4j finden sich auf der Projektseite [Log]). Neben dem Zähler wird bei dem Logeintrag die übergebene Methodensignatur der Testmethode geloggt. Diese lässt sich in AspectJ über das Objekt thisjoinpointstaticpart ermitteln (vgl. [Boe06] S. 65ff.), welches Zugriff auf den Kontext des Joinpoints ermöglicht. 49

58 Für den Before-Advice der Joinpoints, die durch den Pointcut theorysniffer() beschrieben sind, wird im Prinzip gleichermaßen verfahren. Da aber bei JUnit Theorien die Besonderheit besteht, dass sie je nach Parametrisierung mehrfach ausgeführt werden (vgl. Abschnitt 2.3.2, S. 9), vom JUnit Framework aber nur als eine Testmethode gezählt werden (Anzahl Runs), ist der Advice erweitert worden (vgl. Listing 15 Zeile 10ff.). Es wird ein synchronisiertes java.util.hashset verwendet, welches alle bereits ausgeführten Theorien vorhält. Ist eine Theorie bereits im HashSet vermerkt, so wird kein Logeintrag geschrieben und auch der Zähler wird nicht inkrementiert. Somit erhält man das gleiche Ergebnis wie JUnit, nämlich dass jede Theorie auch wirklich nur als eine Testmethode zählt, egal welche Datenkombinationen sie besitzt. Um zu ermitteln, welche MUTs durch die Testmethoden ausgeführt werden, wurde ein weiterer Pointcut implementiert, der alle Methoden im Quelltext des zugrunde liegenden Testprojektes als Joinpoints definiert (siehe Listing 16). 1 2 public pointcut ezunitsourcemarker ( ) : 3 ( execution ( r e f u n i t... (.. ) ) &&! within ( r e f u n i t. t e s t s.. ) ) 4 ( execution ( r e f u n i t... new (.. ) ) &&! within ( r e f u n i t. t e s t s.. ) ) 5 ( execution ( org. r e f u n i t... (.. ) ) &&! within ( org. r e f u n i t. t e s t s.. ) ) 6 ( execution ( org. r e f u n i t... new (.. ) ) &&! within ( org. r e f u n i t. t e s t s.. ) ) ; Listing 16: Pointcuts für die Joinpoints zur Ausführung von MUTs Der Pointcut ezunitsourcemarker() beschreibt alle Methoden- und Konstruktorausführungen der Pakete org.refunit und refunit, sowie deren Unterpakete. Ausgenommen sind Methoden und Konstruktoren, die sich in den Paketen org.refunit.tests und refunit.tests bzw. deren Unterpaketen befinden. Dabei handelt es sich um die Pakete, die die Tests des Projektes enthalten. Diese sind nicht als MUTs anzusehen und werden daher nicht berücksichtigt. Erreicht wird das durch den negierten within- Pointcut (vgl. hierzu [Boe06] S. 108 ff.). Der folgende Before-Advice wird für die durch den Pointcut ezunitsourcemarker() adressierten Joinpoints ausgeführt (siehe Listing 17). Ähnlich wie bei dem Before-Advice für den Pointcut theorysniffer() aus Listing 15 wird nicht für jeden Methodenaufruf ein Logeintrag geschrieben, da MUTs durchaus mehrfach ausgeführt werden können. Auch hierfür wurde ein synchronisiertes java.util.hashset verwendet, das zunächst auf das Vorkommen einer Methode überprüft wird. Nur für Methoden, die erstmalig ausgeführt werden, wird ein Logeintrag geschrieben. Das ist ausreichend, da auch in EzUnit jede MUT nur ein einziges Mal für die Matrixbildung verwendet wird, auch wenn sie von mehreren Testmethoden aufgerufen wird. 50

59 1 before ( ) : 2 ezunitsourcemarker ( ) { 3 S t r i n g s i g n a t u r e = thisjoinpointstaticpart. g e t S i g n a t u r e ( ). t o S t r i n g ( ) ; 4 i f (! mutset. c o n t a i n s ( s i g n a t u r e ) ) { 5 mutset. add ( s i g n a t u r e ) ; 6 l o g g e r. i n f o ( MUT c a l l e d f i r s t by + this. currenttestmethod ) ; 7 l o g g e r. i n f o ( s i g n a t u r e ) ; 8 } 9 } Listing 17: Before-Advice für den Pointcut aus Listing 16 Um den Aspekt Taspect für eines der RefUnit Projekte ausführen zu können, muss die Datei Taspect.aj in das Projekt kopiert werden. Hierfür empfiehlt es sich, ein neues Paket anzulegen, z.b. mit dem Namen ezunitassistence. Anschließend muss noch die Log4j Library zum Klassenpfad hinzugefügt werden und eine entsprechende Konfigurationsdatei erstellt werden (z.b. log4j.properties). Die Struktur eines so modifizierten RefUnit Projektes ist in Abbildung 10 zu sehen. Abbildung 10: Projektstruktur für ein um Taspect erweitertes RefUnit 4 Projekt Werden nun die Tests des Projektes mit JUnit ausgeführt, protokolliert Taspect die Aufrufreihenfolge von Testmethoden und MUTs EzUnitComparator Um einen Vergleich der ermittelten Methoden durch den Aspekt Taspect und durch EzUnit anstellen zu können, wurde der EzUnitComparator entwickelt. Er vergleicht das durch den Aspekt geschriebene Log mit den in Abschnitt (S. 22) beschriebenen Logausgaben des EzUnit Plug-in Projektes. Im Idealfall sollten die von EzUnit ermittelten MUTs und Testmethoden mit den von Taspect ermittelten übereinstimmen. Ermöglicht wird dieser Vergleich, indem die Logausgaben nacheinander eingelesen, und entsprechend einiger Regeln auf ein gleiches Format gebracht werden. Hierfür wurde eine 51

60 Beanstruktur implementiert, die den Methodennamen und die Parameter der jeweiligen Methode speichert. Collections dieser Beans werden jeweils für die Testmethoden und für die MUTs der Logausgaben erstellt. Bei den Untersuchungen zu dieser Arbeit hat sich herausgestellt, dass in EzUnit jede Methode, die beim Tracing ermittelt wurde, auf ihre Existenz im Sinne von JDT überprüft wird. Die JDT-Methode IMethod.exists() gibt true zurück, wenn die jeweilige Methode im Java Modell des Programms enthalten ist (für mehr Informationen zu JDT siehe [JDT]). Für Methodenaufrufe von anonymen Klassen oder für implizite Konstruktoren gibt IMethod.exists() beispielsweise false zurück. Die Prüfung mit IMethod.exists() findet in der Klasse org.projectory.ezunit. core.ezserver statt. Ein Auszug ist in Listing 18 zu sehen. Methoden für die false zurückgegeben wird, werden von EzUnit nicht als MUTs gezählt (vgl. hierzu auch Listing 7 in Abschnitt 3.3). Um diese Methoden beim Vergleich mit den von Taspect ermittelten MUTs auszuschließen, wurde eine weitere Zeile im EzUnit Quelltext implementiert, um jede durch IMethod.exists() aussortierte Methode zu loggen. Hierfür wurde in der Klasse EzServer in den in Zeile 516 (Revision *9, :34) beginnenden else-block eine Logausgabe implementiert. Der Ausschnitt des else-blockes ist in Listing 18 zu sehen (Zeile 7 im Listing entspricht dabei Zeile 516 im Originalprojekt. Berücksichtigt werden nur Methoden, die sich in einem der RefUnit-Pakete befinden: sprich org.refunit oder refunit (vgl. Zeilen 7-9). Diese Implementierung wurde ebenfalls nur in der Kopie des EzUnit Plug-in Projektes umgesetzt (vgl. hierzu Abschnitt 3.1.3, S. 22). Die Logausgaben zu allen RefUnit Projekten befinden sich auf der beiliegenden CD (siehe Anhang B, S. 82). 1 i f ( method!= null 2 && method. e x i s t s ( ) // c o n s i d e r only e x i s t i n g methods ( non e x i s t i n g methods i n c l u d e f o r example i m p l i c i t c o n s t r u c t o r s ) 3... ) { } else { i f ( l i n e. c o n t a i n s ( r e f u n i t ) ) { 8 l o g g e r. i n f o ( IMethod not found l i n e= + l i n e + classname= + classname + methodname= + methodname) ; 9 } } Listing 18: Implementierung für Logausgaben in der Klasse EzServer Insgesamt ergeben sich für den EzUnitComparator vier Logdateien als Eingabe. Neben der Datei OutputEzUnitIMethodNotFound.log, die die Logausgaben aus der Klasse EzServer beinhaltet, handelt es sich um die Dateien OutputEzUnit.log (mit Logausgaben aus der Klasse MatrixContentProvider, vgl. Abschnitt 3.1.3, S. 22), 52

61 OutputEzUnitResultView.log (mit Logausgaben aus der Klasse RunManager, vgl. Abschnitt 3.1.3, S. 22) und OutputTaspectTrace.log (mit Logausgaben von Taspect, vgl. Abschnitt 5.2.1, S. 48). Die Aufgabe des EzUnitComparators besteht darin, die anhand der vier Logdateien ermittelten Methoden gegeneinander abzugleichen. Die Ergebnisse werden in einer Logdatei ausgegeben und liefern die folgenden Informationen. MUTs, die von Taspect ermittelt, aber im EzUnit Matrix View nicht berücksichtigt werden (ausgeschlossen werden dabei Methoden, die von IMethod.exists() aussortiert wurden). Testmethoden, die von Taspect ermittelt, aber im EzUnit Matrix View nicht berücksichtigt werden. MUTs, die im EzUnit Matrix View berücksichtigt, aber von Taspect nicht ermittelt werden. Testmethoden, die im EzUnit Matrix View berücksichtigt, aber von Taspect nicht ermittelt werden. MUTs, die im EzUnit Result View berücksichtigt werden, aber im EzUnit Matrix View nicht. Testmethoden, die im EzUnit Result View berücksichtigt werden, aber im EzUnit Matrix View nicht. Die Pfadangaben für die Eingabedateien werden in der main-methode des EzUnitComparators gesetzt. Der Pfad für die Ergebnisausgabe wird in der Datei log4j.properties angegeben. Der Quelltext des EzUnitComparators ist auf der CD zu finden, die dieser Arbeit beiliegt (vgl. Anhang B, S. 82). 5.3 Auswertung Die im vorigen Abschnitt vorgestellten Implementierungen werden genutzt, um zu evaluieren, inwiefern die RefUnit Projekte dazu geeignet sind, JUnit als Testprojekt für EzUnit zu ersetzen. 53

62 Von den sechs RefUnit Projekten 14 wurde je eine Kopie erstellt, in die der Aspekt Taspect gemäß Beschreibung (vgl. Abschnitt 5.2.1, S. 48) implementiert wurde. Die in Abschnitt vorgestellten Testsuites wurden anschließend auf den so erzeugten AspectJ-Projekten als JUnit-Testlauf ausgeführt. Die durch den Aspekt Taspect erzeugten Logausgaben wurden schließlich vom EzUnitComparator (vgl. Abschnitt 5.2.2) mit den im EzUnit Plug-in Projekt implementierten Logausgaben verglichen. Die so ermittelten Informationen werden in den nächsten beiden Abschnitten vorgestellt und sollen die unter Abschnitt 4.2 (S. 41) beschriebenen Ergebnisse bewerten. Die AspectJ-Testprojekte sind auf der CD zu finden, die dieser Arbeit beiliegt (vgl. Anhang B, S. 82) Testprojekte RefUnit 3 In diesem Abschnitt werden die Ergebnisse des EzUnitComparators für die RefUnit 3 Projekte analysiert. Listing 25 (S. 69) zeigt exemplarisch die Ausgabe für das Testprojekt RefUnit 3 ohne Fehler. Tabelle 10 illustriert die folgenden vom EzUnitComparator ermittelten Ergebnisse. Sie zeigt die Anzahl der MUTs und Testfälle die von Taspect ermittelt wurden im Vergleich zur Anzahl der MUTs und Testfälle die im EzUnit Matrix View dargestellt wurden. Bei der Anzahl MUTs, die für Taspect angezeigt werden, wurde die Anzahl der Methoden, die durch IMethod.exists() aussortiert wurden, abgezogen. Tabelle 10: Vergleich Taspect und EzUnit Matrix View für RefUnit 3 ohne Fehler Spezialfall Assert allgemeiner Fehlerfall Logausgabe MUTs Testfälle MUTs Testfälle MUTs Testfälle Taspect EzUnit Matrix View Die Ergebnisse der Projekte RefUnit 3 ohne Fehler und Spezialfall Assert RefUnit 3 sind identisch. Das Testprojekt allgemeiner Fehlerfall RefUnit 3 unterscheidet sich minimal von den beiden anderen. Die Anzahl der ermittelten MUTs der Testprojekte durch Taspect ist unterschiedlich. Dies kann auch für die Ausgaben von EzUnit beobachtet werden (vgl. Abschnitt 4.2, S. 41). Die Unterschiede bei der ermittelten Anzahl MUTs der drei Projekte sind darauf zurückzuführen, dass sich die Tracinginformationen je nach auftretenden Fehlern unterscheiden können, da mehr, weniger oder andere Methoden des zu Grunde liegenden Testprojektes aufgerufen werden. Wie bereits in den Abschnitten (S. 41) und (S. 44) beschrieben wurde, werden in EzUnit von den 103 Testmethoden, die JUnit ermittelt hat, nur 97 für die Matrixbil- 14 RefUnit 3 ohne Fehler, allgemeiner Fehlerfall RefUnit 3, Spezialfall Assert RefUnit 3, RefUnit 4 ohne Fehler, allgemeiner Fehlerfall RefUnit 4 und Spezialfall Assert RefUnit 4 54

63 dung im EzUnit Matrix View berücksichtigt. Sechs Testmethoden wurden nicht mit in das Ergebnis einbezogen. Das gilt für alle drei Testprojekte gleichermaßen. Vom Aspekt Taspect konnten dagegen alle 103 Testmethoden ermittelt werden. Eine detaillierte Betrachtung der Testmethoden erklärt jedoch, warum EzUnit diese Testmethoden nicht in die Matrixbildung einbezogen hat. Die Testmethode testnothing() enthält keinen Inhalt (siehe Listing 20, S. 67). Es werden keine weiteren Methoden ausgeführt. Somit können auch keine MUTs ermittelt werden. EzUnit schließt diese Methode daher für die Matrixbildung aus. Die Testmethode testcasetostring() (siehe Listing 21, S. 67) ruft zwar andere Methoden auf, nämlich assertequals(..) und tostring(), diese sind aber beide im Paket junit.framework zu finden und werden daher von EzUnit ausgefiltert. Für die assertequals(..) Methode ist das auch korrekt. Die Methode tostring() müsste eigentlich eine MUT sein, da diese Methode das zu testende Verhalten implementiert. Da die Testklasse selbst aber eine Subklasse junit. framework.testcase ist, ist es folglich auch deren Methode tostring(). Sie wird somit ebenfalls ausgefiltert und nicht mit in die Matrixbildung einbezogen. Um die ursprüngliche Funktion der Testmethode zu erhalten, müsste an dieser Stelle eigentlich ein Aufruf der Methode tostring() der Klasse refunit.framework. TestCase erfolgen. Die Testmethode testsort() ruft, wie in Listing 22 (S. 67) zu sehen ist, die Methode einer Klasse Sorter auf. Da in dieser Klasse allerdings die swap() Methode der inneren Klasse Swapper der Testklasse SorterTest aufgerufen wird, wird auch dieser Methodenaufruf ausgefiltert. Die Methode befindet sich im Paket refunit.tests, welches bei der Ermittlung von MUTs ausgeschlossen wird, da es sich im Quelltextverzeichnis src/test befindet (vgl. hierzu Erläuterung zu Abbildung 5, S. 14). Für die Testmethoden testfailure(), testsuccess() und testerror() wird jeweils, wie in Listing 23 (S. 68) zu sehen ist, eine Methode exectest() aufgerufen. Diese Methode selbst wird ausgefiltert, da sie sich ebenfalls im Quelltextverzeichnis src/test befindet. Zwar wird in der Methode exectest() eine weitere potentielle MUT aufgerufen, allerdings geschieht dies durch das Starten eines weiteren Java- Prozesses in der Runtime; dieser kann von EzUnit nicht erkannt werden. Neben diesen sechs Testmethoden wurden vom EzUnitComparator noch 16 MUTs (Ref- Unit 3 ohne Fehler und Spezialfall Assert RefUnit 3 ) ermittelt, die EzUnit gegenüber Taspect nicht berücksichtigt hat. Beim Testprojekt allgemeiner Fehlerfall RefUnit 3 sind es 15. Untersucht man die 15 bzw. 16 Methoden, so stellt sich heraus, dass diese von den eben beschriebenen Testmethoden aufgerufen werden, die nicht mit in der Matrix 55

64 berücksichtigt werden. Das ist auch der Grund, warum sie nicht als MUTs erkannt werden. Für eine Methode gilt dies jedoch nicht. Dabei handelt es sich um die Methode refunit.extensions.activetestsuite.runfinished(). Die Methode refunit.extensions.activetestsuite.runfinished() muss auch im Zusammenhang mit der Abweichung der Anzahl MUTs im EzUnit Result View und im EzUnit Matrix View genannt werden. Im EzUnit Result View wird eine MUT mehr berücksichtigt als im EzUnit Matrix View. Das gilt für alle drei Projektversionen. Der Grund hierfür ist der folgende: Im EzUnit Result View wird der org.projectory. ezunit.core.uuts.unitunderteststore zur Anzeige verwendet. Dort werden alle Methoden eingetragen, die nicht über IMethod.exists() oder einen der Filter ausgeschlossen werden. Im EzUnit Matrix View werden dagegen die Resultate aus dem org. projectory.ezunit.core.partition.partitionstore verwendet. Dort werden aber nur die MUTs aus dem Tracing verwendet, deren Context oder Parent in der Klasse EzServer in der Methode newline(..) ermittelt werden konnten. Das bedeutet, dass eine MUT entweder einer aufrufenden Testmethode (Context) zugeordnet werden kann, oder einer anderen aufrufenden MUT (Parent). Gibt es keinen Parent oder Context, wird die Methode hier nicht berücksichtigt. Das ist bei der Methode refunit.extensions. ActiveTestSuite.runFinished() der Fall. Diese wird statisch aufgerufen. EzUnit ist es somit nicht möglich, die Aufrufreihenfolge zu ermitteln. Bei den Testmethoden wurden ebenfalls unterschiedliche Anzahlen im EzUnit Result View und im EzUnit Matrix View ermittelt. Im EzUnit Matrix View werden in allen drei RefUnit 3 Projekten sieben Testmethoden weniger gezählt als im EzUnit Result View. Dabei handelt es sich um die gleichen Methoden, die bereits im Zusammenhang mit den Unterschieden im EzUnit Matrix View und den Logausgaben von Taspect genannt wurden. Warum die Testmethoden im EzUnit Matrix View nicht berücksichtigt werden, wurde bereits erläutert. Im EzUnit Result View sind sie dagegen vorhanden, weil die Ergebnisse dort direkt über den Test Run Listener (vgl. Abschnitt 2.4, S. 12) ermittelt werden Testprojekte RefUnit 4 Im Folgenden werden die Ergebnisse des EzUnitComparators für die RefUnit 4 Projekte diskutiert. Exemplarisch wird das Ergebnis für das Testprojekt RefUnit 4 ohne Fehler in Listing 26 (S. 70) gezeigt. Die Ergebnisse des EzUnitComparators für die RefUnit 4 Projekte werden analog zur Darstellung der RefUnit 3 Projekte (vgl. Tabelle 10, S. 54) in Tabelle 11 illustriert. Von den Ergebnissen für Taspect wurden wieder die durch IMethod.exists() aussortierten Methoden abgezogen. Von den Ergebnissen des EzUnit Matrix Views wurden die jeweils 13 Hamcrest-Methoden abgezogen die EzUnit als MUTs ermittelt hat (siehe Listing 26, S. 70), da Taspect bei der MUT-Ermittlung lediglich Methoden aus den RefUnit-Paketen berücksichtigt (vgl , S. 48). 56

65 Tabelle 11: Vergleich Taspect und EzUnit Matrix View für RefUnit 4 ohne Fehler Spezialfall Assert allgemeiner Fehlerfall Logausgabe MUTs Testfälle MUTs Testfälle MUTs Testfälle Taspect EzUnit Matrix View EzUnit hat gegenüber Taspect 17 Testmethoden weniger ermittelt. Zusammen mit den drei markierten Testmethoden ergeben sich daraus die 20 Testmethoden, die im EzUnit Matrix View gegenüber den von JUnit ermittelten Runs fehlen (vgl. Tabelle 13, S. 74 und Auflistung aus Abschnitt 4.2.4, S. 45). Für fünf der Testmethoden (testcasetostring(), testnothing(), testfailure(), testsuccess() und testerror()) gelten die bereits unter Abschnitt ausgeführten Erklärungen. Die restlichen zwölf Testmethoden sollen hier im Detail untersucht werden. Für die Testmethode failurecausesexitcodeof1() wird ähnlich, wie bei den Testmethoden testerror(), testfailure() und testsuccess(), ein weiterer Prozess in der Runtime gestartet, wodurch EzUnit keine MUTs ermitteln kann, und die Testmethode daher nicht im EzUnit Matrix View aufführt. Die Testmethode characterizecreatingmyownannotation() (vgl. Listing 24, S. 68) ruft die Methode einer Klasse auf, die sie selbst implementiert. Diese wird aufgrund der Filterfunktion des Quelltextverzeichnisses src/test ebenfalls nicht als MUT gezählt. Da die Testmethode keine weiteren MUTs enthält, wird sie von der Matrixbildung im EzUnit Matrix View ausgeschlossen. Bei den restlichen zehn Testmethoden handelt es sich um JUnit Theorien, die von Ez- Unit nicht unterstützt werden. EzUnit erkennt die Testfälle, die annotiert wurden, nicht als Testmethoden. Es werden lediglich Methoden erkannt, die mit der annotiert sind, oder deren Name mit dem Präfix test beginnt. Verantwortlich hierfür ist die Methode istestmethod(..) der Klasse org.projectory. ezunit.core.util.utilities, die die Überprüfung vornimmt, ob eine Methode eine Testmethode ist. Listing 19 zeigt einen Ausschnitt der Methode istestmethod(..) der Klasse Utilities (Revision * :34). 1 public s t a t i c boolean istestmethod ( IMethod methodtocheck, boolean f a s t ) { i f ( methodtocheck. getelementname ( ). startswith ( t e s t ) 4 methodtocheck. getsource ( ). c o n t a i n s ) ) 5 return methodtocheck. g e t S i g n a t u r e ( ). e q u a l s ( ( )V ) ; 6 } } Listing 19: Ausschnitt der Methode istestmethod(..) der Klasse Utilities 57

66 Neben der Überprüfung, ob eine Testmethode mit der versehen ist, oder das Namenspräfix test hat, wird geprüft, ob die Methode keine Parameter und Rückgabewerte hat (vgl. [Ber10] zur Darstellung von Methodensignaturen in EzUnit). In Abschnitt 3.3 (S. 30) wurde bereits erläutert, warum im EzUnit Result View die Anzahl der ermittelten Testmethoden, nicht mit den von JUnit ermittelten übereinstimmt, obwohl diese Informationen direkt vom implementierten Test Run Listener, also JUnit selbst, bereitgestellt werden. Auffällig ist an dieser Stelle, dass es sich bei den ausgeschlossenen zehn Testmethoden um die Theorien handelt, die auch im EzUnit Matrix View nicht berücksichtigt werden. Analog zu Abschnitt sollen nun noch die MUTs, die EzUnit ermittelt hat, anhand der Logausgaben von Taspect überprüft werden. Gegenüber den von Taspect ermittelten MUTs hat EzUnit 15 Methoden für die Testprojekte RefUnit 4 ohne Fehler und allgemeiner Fehlerfall RefUnit 4 nicht ermittelt und zehn für das Projekt Spezialfall Assert RefUnit 4. Acht der ermittelten Methoden sind identisch mit acht der für die RefUnit 3 Projekte ermittelten (vgl. Listing 25, S. 69). Die bereits in Abschnitt (S. 54) beschriebenen Erläuterungen sind hier gleichermaßen zutreffend. Die restlichen sieben Methoden werden im Folgenden genauer untersucht: Die Methode org.refunit.internal.runners.rules.rulefieldvalidator(..) wurde von der Methode IMethod.exists() von der Matrixbildung ausgeschlossen. Sie wurde vom EzUnitComparator allerdings nicht erkannt, da die unterschiedliche Darstellung der Übergabeparameter nicht von den Parser-Regeln erfasst wurde. Da es sich dabei um einen Einzelfall handelt, wurde der EzUnitComparator nicht weiter angepasst. Die drei Methoden org.refunit.experimental.results.failurelist(..), org. refunit.experimental.results.failurelist.result() und org.refunit.experimental.results.printableresult(..) werden von Testmethoden ausgeführt, die nicht mit in die Matrixbildung einbezogen wurden; somit werden sie von EzUnit auch nicht als MUTs erkannt. Die Methode org.refunit.runner.notification.runnotifier.pleasestop() und der Konstruktor org.refunit. experimental.max.maxhistory(..) werden je für ein Objekt aufgerufen, das in der ausführenden Testmethode selbst erzeugt wird. Somit werden die Aufrufe nicht als MUTs gewertet, da sie innerhalb des Quelltextverzeichnisses src/test liegen. Für die Methode org.refunit.internal.runners.statements.failontimeout. StatementThread.run() gilt das gleiche wie bereits für die Methode refunit. extensions.activetestsuite.runfinished(), nur dass die Methode nicht statisch aufgerufen wird. Bei der Methode run() handelt es sich um eine überschriebe- 58

67 ne Methode der Klasse java.lang.thread, einer privaten inneren Klasse. Auch sie wird nicht mit in den PartitionStore übernommen (vgl. Abschnitt 5.3.1, S. 54). Mit Ausnahme der Methode RuleFieldValidator(..) sind die beschriebenen Methoden auch diejenigen, die im EzUnit Result View berücksichtigt werden, im EzUnit Matrix View aber nicht. Außerdem wurde im EzUnit Result View eine andere Anzahl an Testmethoden ermittelt als im EzUnit Matrix View. Bei den nicht berücksichtigten Testmethoden handelt es sich um die bereits in Abschnitt (S. 42) aufgelisteten. Eine Erklärung, warum die einzelnen Methoden und Testmethoden im EzUnit Matrix View nicht berücksichtigt werden, wurde bereits in diesem und im vorangegangenen Abschnitt gegeben. Die Anzahl der ermittelten MUTs unterscheidet sich auch bei den RefUnit 4 Projekten. Sowohl bei den EzUnit Ergebnissen, als auch bei den Ergebnissen von Taspect, werden für die verschiedenen Projekte unterschiedliche Zahlen ermittelt. Eine Erklärung hierfür wurde ebenfalls im vorherigen Abschnitt für die RefUnit 3 Projekte gegeben Fazit Die Testmethoden und MUTs, die von EzUnit nicht berücksichtigt wurden, nachdem das Refactoring auf dem JUnit Projekt ausgeführt wurde, lassen sich nicht auf die in der Analyse (vgl. Abschnitt 3.3, S. 30) vorgefundene Problematik zurückführen. Die Erklärung für die nicht berücksichtigten Methoden sind allgemeingültig und von der Implementierung des EzUnit Plug-in Projektes abhängig. Das Refactoring des JUnit Projektes liefert somit einen brauchbaren Lösungsansatz, der es ermöglicht, JUnit als Testprojekt für EzUnit zu verwenden. Der Lösungsansatz lässt sich beliebig auf andere JUnit Versionen übertragen. Ein Selbsttest von JUnit ist somit möglich, ohne dass Anpassungen am EzUnit Plug-in Projekt vorgenommen werden müssen. Dennoch sollen im folgenden Kapitel einige Empfehlungen für die Weiterentwicklung von EzUnit und die Verbesserung der Unterstützung von JUnit als Testprojekt gegeben werden. 59

68 6 Zusammenfassung Im Rahmen dieser Bachelorarbeit wurden die Probleme, die JUnit als Testprojekt für EzUnit verursacht, im Detail betrachtet und analysiert. Als wichtigste Ursachen für die auftretenden Probleme haben sich dabei die Filterfunktionen von EzUnit herausgestellt. Bei der Verwendung von JUnit als Testprojekt kann keine klare Unterscheidung zwischen Testprojekt und Testframework getroffen werden, wie es bei anderen Testprojekten der Fall ist. Außerdem hat sich bei den Untersuchungen herausgestellt, dass auch das JUnit Framework selbst Probleme bei einem Selbsttest aufzeigt. Im Zuge dessen, wurde ein Refactoring der verwendeten JUnit Testprojekte als Lösung vorgeschlagen und umgesetzt. Auch wenn das Refactoring des JUnit Projektes eine einfache und wirksame Methode darstellt, JUnit als Testprojekt für EzUnit zu nutzen, sollten dennoch einige Anpassungen am EzUnit Plug-in Projekt vorgenommen werden, um zukünftig auch die durch das Refactoring nicht lösbaren Probleme zu vermeiden. Bei diesen Problemen handelt es sich um die Verwendung der Maven Paket-Struktur für Testprojekte, die fehlende Unterstützung von JUnit 4 Theorien und die mangelnde Unterstützung einiger Java Sprachkonstrukte, wie zum Beispiel die Berücksichtigung von anonymen Klassen bei der MUT Ermittlung. Im Folgenden werden Empfehlungen für die Anpassung des EzUnit Plug-in Projektes zur Behebung dieser Probleme gegeben. Anpassung der Filterfunktion Es ist sinnvoll, die Exclude Source Folders-Filterfunktion dahingehend zu überarbeiten, dass es möglich ist, die Maven Paket-Struktur für Projekte zu nutzen. Dies würde einen EzUnit Test der so organisierten Projekte vereinfachen. Dazu sollte die Methode excludedpackagesfragmentroot(..) in der Klasse EzServer überarbeitet werden, so dass hierarchische Verzeichnis-Strukturen als Quelltextverzeichnisse angegeben werden können (vgl. Abschnitt 3.3, S. 30). Unterstützung von JUnit Theorien Ebenfalls in EzUnit eingeführt werden sollten die neuen Sprachkonstrukte von JUnit, wie z.b. Theorien. Diese werden aktuell nicht unterstützt und verhindern, dass Theorien als Testmethoden erkannt werden. Hierfür sollte die Methode istestmethod(..) der Klasse EzServer entsprechend angepasst werden (vgl. Abschnitt 3.3, S. 30). Ermittlung von MUTs im EzUnit Matrix View Es ist zu überlegen, inwieweit die Methode EzServer.newLine(..) überarbeitet werden kann. Aktuell werden eine Reihe von Methoden allein durch die Methode IMethod.exists() von JDT als MUTs ausgeschlossen. Durch den EzUnitComparator ließen sich für die RefUnit 4 Projekte beispielsweise 198 Methoden ermitteln, die so für die Matrixbildung von EzUnit unberücksichtigt blieben. Dies ist eine nicht unerhebliche Anzahl an Methoden, die potentiell fehlerhaft sein könnten (vgl. Abschnitt 5.2.2, S. 51). 60

69 Ermittlung von Testmethoden im EzUnit Result View Eine ähnliche Überlegung schließt sich für die Methode TestMethodStore.testCaseElementToMethod(..) an. Diese schließt Testmethoden für die Anzeige der Ergebnisse Passed tests und Failed tests im EzUnit Result View aus, obwohl diese korrekt vom implementierten Test Run Listener übermittelt werden. Hierfür wird eine weitere von JDT bereitgestellte Methode eingesetzt, die einige Methoden von der Anzeige ausschließt (vgl. Abschnitt 3.3, S. 30). 61

70 Abbildungsverzeichnis 1 Aufbau der Eclipse Architektur nach [Hol09] Exemplarisches Testergebnis von JUnit Paket-Struktur von JUnit Paket-Struktur von JUnit Filtereinstellungen von EzUnit EzUnit Views Erweiterte Filterfunktion Exclude Packages für EzUnit Eingabemaske für die Eclipse Rename-Funktion auf dem Paket org.junit 35 9 Paket-Struktur RefUnit 4 ohne Fehler Projektstruktur für ein um Taspect erweitertes RefUnit 4 Projekt Beispiel zur Verwendung von parametrisierten Tests in JUnit Beispiel zur Verwendung von Theorien in JUnit EzUnit Testlaufs ohne Fehler - Beispielprojekt SimpleIntCalculatorV

71 Listings 1 Auszug Beispiel Testfall in JUnit Auszug Beispiel Testfall in JUnit Zeilen 242 bis 245 der Klasse RunManager Logausgaben und Korrektur in der Klasse RunManager Zeilen 60 und 61 der Klasse MatrixContentProvider Logausgaben in der Klasse MatrixContentProvider Ausschnitt der Methode newline(..) der Klasse EzServer Auszug eines RefUnit 3 Testfalls Teil Auszug eines RefUnit 3 Testfalls Teil Auszug der Testklasse SuiteTest aus einem JUnit 3 Projekt Auszug eines RefUnit 3 Testfalls Teil Auszug eines RefUnit 3 Testfalls mit geänderter Paket-Struktur Beispiel eines RefUnit 4 Testfalls mit Theorien Pointcuts die Joinpoints zur Ausführung der Testmethoden beschreiben Before-Advices für die Pointcuts aus Listing Pointcuts für die Joinpoints zur Ausführung von MUTs Before-Advice für den Pointcut aus Listing Implementierung für Logausgaben in der Klasse EzServer Ausschnitt der Methode istestmethod(..) der Klasse Utilities NoArgTestCaseTest.testNothing() TestCaseTest.testCaseToString() SorterTest.testSort() TextRunnerTest.testFailure() testsuccess() testerror() AnnotatedDescriptionTest.characterizeCreatingMyOwnAnnotation() Ergebnis EzUnitComparator für RefUnit 3 ohne Fehler Ergebnis EzUnitComparator für RefUnit 4 ohne Fehler

72 Tabellenverzeichnis 1 Aufbau einer Test Coverage Matrix (TCM) nach [SF10] Ergebnisse Analyse Testprojekt JUnit 3 ohne Fehler Ergebnisse Analyse Testprojekt JUnit 4 ohne Fehler Ergebnisse Analyse Testprojekt JUnit 3 mit injizierten Fehlern Ergebnisse Analyse Testprojekt JUnit 4 mit injizierten Fehlern Ergebnisse Testprojekt RefUnit 3 ohne Fehler Ergebnisse Testprojekt RefUnit 4 ohne Fehler Ergebnisse Testprojekt RefUnit 3 mit injizierten Fehlern Ergebnisse Testprojekt RefUnit 4 mit injizierten Fehlern Vergleich Taspect und EzUnit Matrix View für RefUnit Vergleich Taspect und EzUnit Matrix View für RefUnit Unterschiede Testfallanzahl JUnit und EzUnit - Testprojekte JUnit Unterschiede Testfallanzahl JUnit und EzUnit - Testprojekte RefUnit Nachbearbeitete Klassen in den RefUnit 3 Projekten Nachbearbeitete Klassen in den RefUnit 4 Projekten

73 Literatur [AJDT] Projektseite AJDT: AspectJ Development Tools. ajdt/ [Bal98] H. Balzert Lehrbuch der Software-Technik, Software-Management Software-Qualitätssicherung Unternehmensmodellierung. Seite 395, Spektrum Akademischer Verlag. [Bec09] K. Beck JUnit - pocket guide: quick lookup and advice. O Reilly Media, 92 S. [Ber10] M. Bertschler Automatische Fehlerlokalisierung unter Berücksichtigung der möglichen Anzahl von Fehlern. Master s thesis, Fernuniversität in Hagen. [Boe06] O. Böhm Aspektorientierte Programmierung mit AspectJ 5. dpunkt.verlag, 434 S. [CR08] E. Clayberg, D. Rubel Eclipse Plug-ins (3rd Edition). Addison-Wesley Professional, 928 S. [EzU5] Projektseite EzUnit - Easing the Debugging of Unit Test Failures. fernuni-hagen.de/ps/prjs/ezunit5/ [Ham] Projektseite Hamcrest - library of matchers for building test expressions http: //code.google.com/p/hamcrest/ [Hol09] S. Holzner Eclipse: A Java Developer s Guide. O Reilly Media, 317 S. [JDT] Eclipse Java development tools Projektseite [JIP] Projektseite JIP The Java Interactive Profiler. net [JU] JUnit Projektseite [JU3S] JUnit Quelltext. maven2/junit/junit/3.8.2/ [JU3T] JUnit Tests / [JU4] K. Beck. JUnit 4.10 Quelltext und Tests. junit/downloads [Log] Projektseite Apache Log4j TM

74 [Mey07] Nils Meyer Ein Eclipse-Framework zur Markierung von logischen Fehlern im Quellcode. Master s thesis, Fernuniversität in Hagen. [OCP09] M. Odea Ching, B. Porter Apache Maven 2 Effective Implementation. Packt Publishing, 456 S. [SEES08] F. Steimann, T. Eichstädt-Engelen, M. Schaaf Towards Raising the Failure of Unit Tests to the Level of Compiler-Reported Errors. Technical report, FernUuniveristät in Hagen. [SF10] F. Steimann, M. Frenkel Improving Coverage-Based Localization of Multiple Faults Using Algorithms from Integer Linear Programming. In 23rd IEEE International Symposium on Software Reliability Engineering (ISSRE). [Ste05] F. Steimann Moderne Programmiertechniken und -methoden. Kurstext Kurseinheit 3, Fernuniversität in Hagen [TLMG11] P. Tahchiev, F. Leme, V. Massol, G. Gregory JUnit IN ACTION: second edition. Manning Publications Co., 467 S. [Ull11] C. Ullenboom Java ist auch eine Insel: Das umfassende Handbuch. Galileo Computing, 1308 S. 66

75 A Anhang 1 public c l a s s NoArgTestCaseTest extends j u n i t. framework. TestCase { 2 public void testnothing ( ) { 3 } 4 } Listing 20: NoArgTestCaseTest.testNothing() 1 public void testcasetostring ( ) { 2 Assert 3. a s s e r t E q u a l s ( testcasetostring ( r e f u n i t. t e s t s. framework. TestCaseTest ), t o S t r i n g ( ) ) ; 4 } Listing 21: TestCaseTest.testCaseToString() 1 public void t e s t S o r t ( ) throws Exception { 2 Vector v= new Vector ( ) ; 3 v. addelement ( c ) ; 4 v. addelement ( b ) ; 5 v. addelement ( a ) ; 6 S o r t e r. s o r t S t r i n g s ( v, 0, v. s i z e ( ) 1, new Swapper ( ) ) ; 7 Assert. a s s e r t E q u a l s ( v. elementat ( 0 ), a ) ; 8 Assert. a s s e r t E q u a l s ( v. elementat ( 1 ), b ) ; 9 Assert. a s s e r t E q u a l s ( v. elementat ( 2 ), c ) ; 10 } static class Swapper implements S o r t e r. Swapper { 13 public void swap ( Vector values, int l e f t, int r i g h t ) { 14 Object tmp= v a l u e s. elementat ( l e f t ) ; 15 v a l u e s. setelementat ( v a l u e s. elementat ( r i g h t ), l e f t ) ; 16 v a l u e s. setelementat (tmp, r i g h t ) ; 17 } 18 } Listing 22: SorterTest.testSort() 67

76 1 public void t e s t F a i l u r e ( ) throws Exception { 2 exectest ( r e f u n i t. t e s t s. framework. F a i l u r e, f a l s e ) ; 3 } 4 5 public void t e s t S u c c e s s ( ) throws Exception { 6 exectest ( r e f u n i t. t e s t s. framework. Success, true ) ; 7 } 8 9 public void t e s t E r r o r ( ) throws Exception { 10 exectest ( r e f u n i t. t e s t s. BogusDude, f a l s e ) ; 11 } void exectest ( S t r i n g t e s t C l a s s, boolean s u c c e s s ) throws Exception { 14 S t r i n g java= System. getproperty ( java. home ) + F i l e. s e p a r a t o r + 15 bin + F i l e. s e p a r a t o r + java ; 16 S t r i n g cp= System. getproperty ( java. c l a s s. path ) ; 17 // use c l a s s p a t h f o r JDK c o m p a t i b i l i t y 18 S t r i n g [ ] cmd= { java, c l a s s p a t h, cp, 19 r e f u n i t. t e x t u i. TestRunner, t e s t C l a s s } ; 20 Process p= Runtime. getruntime ( ). exec (cmd) ; 21 InputStream i= p. getinputstream ( ) ; 22 while ( ( i. read ( ) )!= 1) 23 ; // System. out. w r i t e ( b ) ; 24 Assert. a s s erttrue ( ( p. waitfor ( ) == 0) == s u c c e s s ) ; 25 i f ( s u c c e s s ) 26 Assert. a s s erttrue ( p. exitvalue ( ) == 0) ; 27 else 28 Assert. a s s e r t F a l s e ( p. exitvalue ( ) == 0) ; 29 } Listing 23: TextRunnerTest.testFailure() testsuccess() testerror() 2 public void characterizecreatingmyownannotation ( ) { 3 Annotation annotation= new Ignore ( ) { 4 public S t r i n g value ( ) { 5 return message ; 6 } 7 public C l a s s <? extends Annotation> annotationtype ( ) { 8 return Ignore. class ; 9 } 10 } ; 11 org. j u n i t. Assert. a s s e r t E q u a l s ( Ignore. class, 12 annotation. annotationtype ( ) ) ; 13 } Listing 24: AnnotatedDescriptionTest.characterizeCreatingMyOwnAnnotation() 68

77 1 Anzahl MUTs Taspect Log : Anzahl T e s t c a s e s Taspect Log : Anzahl MUTs EzUnit Matrix View : Anzahl T e s t c a s e s EzUnit Matrix View : 97 5 Anzahl IMethod not found : Anzahl MUTs EzUnit R e s u l t View : Anzahl T e s t c a s e s EzUnit Result View : COMPARE Found i n Taspect but not i n EzUnit Log 10 could not f i n d f o l l o w i n g muts : 11 imethodfiltercounter : ) r e f u n i t. t e x t u i. TestRunner. runfailed 13 S t r i n g 14 2) r e f u n i t. runner. S o r t e r. s o r t S t r i n g s 15 Vector 16 int 17 int 18 S o r t e r. Swapper 19 3) r e f u n i t. runner. BaseTestRunner. c l e a r S t a t u s 20 4) r e f u n i t. t e x t u i. R e s u l t P r i n t e r. p r i n t D e f e c t 21 T e s t F a i l u r e 22 int 23 5) r e f u n i t. framework. TestCase. t o S t r i n g 24 6) r e f u n i t. t e x t u i. R e s u l t P r i n t e r. p r intdefecttrace 25 T e s t F a i l u r e 26 7) r e f u n i t. t e x t u i. TestRunner. main 27 S t r i n g [ ] 28 8) r e f u n i t. t e x t u i. R e s u l t P r i n t e r. printdefectheader 29 T e s t F a i l u r e 30 int 31 9) r e f u n i t. runner. StandardTestSuiteLoader. load 32 S t r i n g 33 10) r e f u n i t. runner. StandardTestSuiteLoader 34 11) r e f u n i t. framework. T e s t F a i l u r e. t r a c e 35 12) r e f u n i t. framework. T e s t F a i l u r e. f a i l e d T e s t 36 13) r e f u n i t. t e x t u i. TestRunner. s t a r t 37 S t r i n g [ ] 38 14) r e f u n i t. e x t e n s i o n s. A ctivetestsuite. runfinished 39 15) r e f u n i t. framework. TestCase. getname 40 16) r e f u n i t. t e x t u i. TestRunner. getloader could not f i n d f o l l o w i n g t e s t c a s e s : 43 1) testcasetostring 44 2) testnothing 45 3) t e s t S o r t 46 4) t e s t E r r o r 47 5) t e s t S u c c e s s 48 6) t e s t F a i l u r e 49 69

78 50 COMPARE Found i n EzUnit but not i n Taspect Log 51 could not f i n d f o l l o w i n g muts : could not f i n d f o l l o w i n g t e s t c a s e s : COMPARE Found i n EzUnit R e s u l t View Log but not i n EzUnit Matrix View Log 56 could not f i n d f o l l o w i n g muts : 57 1) r e f u n i t. e x t e n s i o n s. A ctivetestsuite. runfinished could not f i n d f o l l o w i n g t e s t c a s e s : 60 1) testcasetostring 61 2) testnothing 62 3) t e s t S o r t Listing 25: Ergebnis EzUnitComparator für RefUnit 3 ohne Fehler 1 Anzahl MUTs Taspect Log : Anzahl T e s t c a s e s Taspect Log : Anzahl MUTs EzUnit Matrix View : Anzahl T e s t c a s e s EzUnit Matrix View : Anzahl IMethod not found : Anzahl MUTs EzUnit R e s u l t View : Anzahl T e s t c a s e s EzUnit Result View : COMPARE Found i n Taspect but not i n EzUnit Log 10 could not f i n d f o l l o w i n g muts : 11 imethodfiltercounter : ) r e f u n i t. t e x t u i. R e s u l t P r i n t e r. p r i n t D e f e c t 13 T e s t F a i l u r e 14 int 15 2) org. r e f u n i t. runner. n o t i f i c a t i o n. RunNotifier. p l easestop 16 3) r e f u n i t. t e x t u i. R e s u l t P r i n t e r. p r intdefecttrace 17 T e s t F a i l u r e 18 4) r e f u n i t. t e x t u i. TestRunner. main 19 S t r i n g [ ] 20 5) org. r e f u n i t. i n t e r n a l. runners. r u l e s. R u l e F i e l d V a l i d a t o r 21 S t r i n g 22 int 23 Class 24 boolean 25 boolean 26 6) org. r e f u n i t. experimental. r e s u l t s. F a i l u r e L i s t. r e s u l t 27 7) r e f u n i t. t e x t u i. TestRunner. runfailed 28 S t r i n g 29 8) r e f u n i t. framework. T e s t F a i l u r e. t r a c e 30 9) org. r e f u n i t. experimental. r e s u l t s. P r i n t a b l e R e s u l t 31 L i s t 32 10) r e f u n i t. e x t e n s i o n s. A ctivetestsuite. runfinished 33 11) r e f u n i t. t e x t u i. R e s u l t P r i n t e r. printdefectheader 70

79 34 T e s t F a i l u r e 35 int 36 12) org. r e f u n i t. experimental. r e s u l t s. F a i l u r e L i s t 37 L i s t 38 13) org. r e f u n i t. experimental. max. MaxHistory 39 F i l e 40 14) org. r e f u n i t. i n t e r n a l. runners. statements. FailOnTimeout. StatementThread. run 41 15) r e f u n i t. framework. T e s t F a i l u r e. f a i l e d T e s t could not f i n d f o l l o w i n g t e s t c a s e s : 44 1) testcasetostring 45 2) testnothing 46 3) t e s t F a i l u r e 47 4) t e s t S u c c e s s 48 5) t e s t E r r o r 49 6) failurecausesexitcodeof1 50 7) characterizecreatingmyownannotation 51 8) b o t h F a i l s 52 9) d e s c r i p t i o n I s S e n s i b l e ) threeandswork ) threeorswork 55 12) tostringreportsmatcher 56 13) tostringreportsvalue ) backtracehasgoodtostring 58 15) i n c l u d e M u l t i p l e F a i l u r e s ) showfailedassumptionswhennoparametersfound 60 17) d i f f e r e n t M a t c h e r s H a v e D i f f e r e n t D e s c r i p t i o n s COMPARE Found i n EzUnit but not i n Taspect Log 63 could not f i n d f o l l o w i n g muts : 64 1) org. hamcrest. S t r i n g D e s c r i p t i o n. append 65 char 66 2) org. hamcrest. BaseMatcher 67 3) org. hamcrest. BaseDescription 68 4) org. hamcrest. BaseDescription. tojavasyntax 69 char 70 5) org. hamcrest. CoreMatchers. nullvalue 71 6) org. hamcrest. core. I s N u l l. notnullvalue 72 7) org. hamcrest. CoreMatchers. notnullvalue 73 8) org. hamcrest. BaseMatcher. t o S t r i n g 74 9) org. hamcrest. core. IsAnything 75 10) org. hamcrest. core. I s N u l l 76 11) org. hamcrest. S t r i n g D e s c r i p t i o n. t o S t r i n g 77 12) org. hamcrest. S t r i n g D e s c r i p t i o n 78 13) org. hamcrest. core. I s N u l l. nullvalue could not f i n d f o l l o w i n g t e s t c a s e s : 81 71

80 82 COMPARE Found i n EzUnit R e s u l t View Log but not i n EzUnit Matrix View Log 83 could not f i n d f o l l o w i n g muts : 84 1) org. r e f u n i t. runner. n o t i f i c a t i o n. RunNotifier. p l easestop 85 2) org. r e f u n i t. experimental. r e s u l t s. F a i l u r e L i s t. r e s u l t 86 3) org. r e f u n i t. experimental. r e s u l t s. P r i n t a b l e R e s u l t 87 L i s t 88 4) r e f u n i t. e x t e n s i o n s. A ctivetestsuite. runfinished 89 5) org. r e f u n i t. experimental. r e s u l t s. F a i l u r e L i s t 90 L i s t 91 6) org. r e f u n i t. experimental. max. MaxHistory 92 F i l e 93 7) org. r e f u n i t. i n t e r n a l. runners. statements. FailOnTimeout. StatementThread. run could not f i n d f o l l o w i n g t e s t c a s e s : 96 1) characterizecreatingmyownannotation 97 2) testnothing 98 3) testcasetostring Listing 26: Ergebnis EzUnitComparator für RefUnit 4 ohne Fehler 72

81 73 Tabelle 12: Unterschiede Testfallanzahl JUnit und EzUnit - Testprojekte JUnit 4 Testfall JUnit EzUnit Diff. org.junit.tests.running.methods.timeouttest 9 (2 ignored) 7 2 org.junit.tests.running.methods.parameterizedtestmethodtest org.junit.tests.assertion.bothtest org.junit.tests.experimental.assumptionviolatedexceptiontest org.junit.tests.experimental.matchertest org.junit.tests.objectcontracttest org.junit.tests.experimental.rules.timeoutruletest 1 (1 ignored) 0 1 org.junit.tests.experimental.theories.parameterizedassertionerrortest org.junit.tests.experimental.theories.runner.successfulwithdatapointfields org.junit.tests.experimental.results.printableresulttest org.junit.tests.experimental.theories.runner.whennoparametersmatch org.junit.tests.experimental.theories.extendingwithstubs.stubbedtheoriestest Gesamt 31

82 Tabelle 13: Unterschiede Testfallanzahl JUnit und EzUnit - Testprojekte RefUnit 4 Testfall JUnit EzUnit Diff. org.refunit.tests.running.methods.timeouttest 9 (2 ignored) 7 2 org.refunit.tests.experimental.rules.timeoutruletest 1 (1 ignored) 0 1 org.refunit.tests.assertion.bothtest org.refunit.tests.experimental.assumptionviolatedexceptiontest org.refunit.tests.experimental.results.printableresulttest org.refunit.tests.experimental.results.printableresulttest org.refunit.tests.experimental.theories.runner.whennoparametersmatch org.refunit.tests.experimental.matchertest Gesamt Testklassen refunit.tests.framework. DoublePrecisionAssertTest2 Tabelle 14: Nachbearbeitete Klassen in den RefUnit 3 Projekten Klasse Beschreibung refunit.tests.framework.failure refunit.tests.framework.inheritedtestcase refunit.tests.framework.onetestcase2 Duplikat der Klasse refunit.tests.framework.doubleprecisionasserttest (Subklasse von junit.framework.testcase) mit Superklasse refunit.framework.testcase Subklasse von refunit.framework.testcase Subklasse von OneTestCase2 (siehe unten) Duplikat der Klasse refunit.tests.framework.onetestcase (Subklasse von junit.framework.testcase) mit Superklasse refunit.framework.testcase

83 75 refunit.tests.framework.noargtestcasetest2 Duplikat der Klasse refunit.tests.framework.noargtestcasetest (Subklasse von junit.framework.testcase) mit Superklasse refunit.framework.testcase refunit.tests.framework.suitetest Korrektur Pfadangaben (Zeilen 94-95) refunit.tests.framework.suitetest2 Duplikat der Klasse refunit.tests.framework.suitetest (Subklasse von junit.framework.testcase) mit Superklasse refunit.framework.testcase refunit.tests.framework.testcasetest Korrektur Pfadangaben (Zeile 32) refunit.tests.framework. DoublePrecisionAssertTest2 Duplikat der Klasse refunit.tests.framework.doubleprecisionasserttest (Subklasse von junit.framework.testcase) mit Superklasse refunit.framework.testcase refunit.tests.runner.basetestrunnertest Korrektur Pfadangaben (Zeile 32) refunit.tests.runner.stackfiltertest Korrektur Pfadangaben (Zeilen 18-21, und 38) refunit.tests.runner. Korrektur Pfadangaben (Zeilen 17, 35 und 30) TestCaseClassLoaderTest refunit.tests.runner.textrunnertest Korrektur Pfadangaben (Zeilen 18, 22, 26 und 33) refunit.tests.runner. Korrektur Pfadangaben (Zeile 70) TextRunnerSingleMethodTest src/test/refunit/tests/runner/test2.jar Hinzufügen der Ressource test2.jar (beinhaltet refunit.tests.runner.loadedfromjar.class) Klassen im Sourcecode refunit.runner.basetestrunner Korrektur Pfadangaben (Zeilen ) refunit.runner.testcaseclassloader Korrektur Pfadangaben (Zeilen 38-40)

84 76 Testklassen refunit.tests.framework. DoublePrecisionAssertTest2 Tabelle 15: Nachbearbeitete Klassen in den RefUnit 4 Projekten Klasse Beschreibung Duplikat der Klasse refunit.tests.framework.doubleprecisionasserttest (Subklasse von junit.framework.testcase) mit Superklasse refunit.framework.testcase Korrektur Pfadangaben (Zeilen 28 und 40) refunit.tests.framework. ComparisonFailureTest refunit.tests.framework.failure Subklasse von refunit.framework.testcase refunit.tests.framework.inheritedtestcase Subklasse von OneTestCase2 (siehe unten) refunit.tests.framework.onetestcase2 Duplikat der Klasse refunit.tests.framework.onetestcase (Subklasse von junit.framework.testcase) mit Superklasse refunit.framework.testcase refunit.tests.framework.suitetest Korrektur Pfadangaben (Zeilen ) refunit.tests.framework.suitetest2 Duplikat der Klasse refunit.tests.framework.suitetest (Subklasse von junit.framework.testcase) mit Superklasse refunit.framework.testcase refunit.tests.framework.testcasetest Korrektur Pfadangaben (Zeile 33) refunit.tests.runner.basetestrunner Korrektur Pfadangaben (Zeile 38) refunit.tests.runner.stackfiltertest Korrektur Pfadangaben (Zeilen 17-20, und 37) refunit.tests.runner. Korrektur Pfadangaben (Zeile 34) TextRunnerSingleMethodTest refunit.tests.runner.textrunnertest Korrektur Pfadangaben (Zeilen 17, 21, 25 und 32) org.refunit.tests.experimental.theories. extendingwithstubs.stubbedtheoriestest Hinzufügen einer Testmethode um die zu testende org.refunit.experimental.theories.theory auszuführen

85 77 org.refunit.tests.experimental.theories. runner.successfulwithdatapointfields org.refunit.tests.experimental.theories. ParameterizedAssertionErrorTest org.refunit.tests.experimental. theoriesparametersignaturetest org.refunit.tests.junit3compatibility. JUnit38ClassRunnerTest org.refunit.tests.running.classes. BlockJUnit4ClassRunnerTest org.refunit.tests.running.core. CommandLineTest org.refunit.tests.running.methods. ParameterizedTestMethodTest org.refunit.tests.objectcontracttest Jede org.junit.theory wurde zu einer org.refunit.theory und für jede Theorie wurde eine entsprechende Testmethode (annotiert mit org.junit.test) zur Ausführung hinzugefügt; Die der Klasse erübrigt sich Jede org.junit.theory wurde zu einer org.refunit.theory und für jede Theorie wurde eine entsprechende Testmethode (annotiert mit org.junit.test) zur Ausführung hinzugefügt Die org.junit.theory wurde zu einer org.refunit.theory und zur Ausführung wurde eine entsprechende Testmethode (annotiert mit org.junit.test) hinzugefügt Korrektur Pfadangaben (Zeile 76) Korrektur Pfadangaben (Zeile 27) Korrektur Pfadangaben (Zeile 33) Der enthaltene parametrisierte org.junit.test wird in einer inneren Klasse als org.refunit.test mit entsprechender Parametrisierung gekapselt und eine org.junit.test Klasse zur Ausführung hinzugefügt. Durch die Änderung, wird von JUnit für die Testklasse anstelle von 1, 3 als Anzahl Runs angezeigt. Die beiden org.junit.theories wurden in zwei inneren Klassen als org.refunit.theories gekapselt und für jede Theorie wurde eine entsprechende Testmethode (annotiert mit org.junit.test) zur Ausführung hinzugefügt

86 org.refunit.tests.internal.runners. statements.failontimeouttest Vier Tests die eine Rule 15 verwenden, wurden in org.refunit.tests geändert und in einer inneren Klasse mit der jeweiligen Rule gekapselt. Zur Ausführung wurden org.junit.tests hinzugefügt. Klassen im Sourcecode refunit.runner.basetestrunner Korrektur Pfadangaben (Zeilen ) org.refunit.experimental.max.maxcore Korrektur Pfadangaben (Zeile 161) Für mehr Informationen zu JUnit Rules sei auf die JUnit Projektseite verwiesen [JU]

87 79 Abbildung 11: Beispiel zur Verwendung von parametrisierten Tests in JUnit 4

88 80 Abbildung 12: Beispiel zur Verwendung von Theorien in JUnit 4

89 81 Abbildung 13: EzUnit Testlaufs ohne Fehler - Beispielprojekt SimpleIntCalculatorV2