Testen mit JUnit. Softwareengineering. Verfasser: Ronny Boost, Michael Künne

Save this PDF as:
 WORD  PNG  TXT  JPG

Größe: px
Ab Seite anzeigen:

Download "Testen mit JUnit. Softwareengineering. Verfasser: Ronny Boost, Michael Künne"

Transkript

1 Testen mit JUnit Softwareengineering Verfasser: Ronny Boost, BA Horb Studiengang: IT Jahrgang: 2003

2 Inhaltsverzeichnis 1 Einleitung oder Was ist JUnit Testarten Unit-Test Integrationstest Blackbox-Test Whitebox-Test Zusammenfassung Testen mit JUnit JUnit Installation Beispiel für einen Test Test Driven Development Vorteile des TDD Nachteile des TDD konventioneller Softwareerstellung vs. TDD Zusammenfassung JUnit Erweiterungen Abbildungsverzeichnis Quellen...22 Ronny Boost

3 1 Einleitung oder Was ist JUnit Wenn man bei Wikipedia unter Junit schaut erhält man folgende Definition: Junit, (Jwnyt), auch Init, eine altägyptische Göttin im Amduat (Totenbuch), die farbige. Abbildung 1.1: altägyptische Göttin Junit Wenn man hingegen nach JUnit sucht erfährt man, dass es sich hierbei um ein Framework zum Testen von Java-Programmen handelt. Hierbei liegt besonderes Augenmerk auf automatisierten Unit-Tests einzelner Klassen. Beim Testen im Allgemeinen handelt es sich nicht um die fälschliche Annahme, zu verifizieren, dass die Anwendung korrekt funktioniert, sondern um das Lokalisieren von Logikfehlern, welche ausschließlich zur Laufzeit auftreten. Bei Unit-Tests, auch Komponententests genannt, im Speziellen geht es um die Validierung einzelner Module einer Software, zum Beispiel einzelner Klassen. Dass das Testen besonders in der Softwareentwicklung einen sehr hohen Stellenwert haben sollte, sieht man bereits an folgenden Zahlen [6]: gefundene Fehler pro 1000 LOC während der Entwicklung Bis zu 3 Fehler pro 1000 LOC nach der Auslieferung Bei sicherheitskritischen Anwendungen ca. 0.5 Fehler pro 1000 LOC OB Wahl in Neu-Ulm 1995: 104% Wahlbeteiligung (tatsächlich 52%) Bluescreen Gepäckverteilungsanlage Flughafen von Denver: 16 Monate Verzögerung, Schaden 550Mio USD Golfkrieg 1991: 28 Tote, fast 100 Verletzte wg. fehlerhafter Uhrsynchronisation Ronny Boost

4 2 Testarten Ein Softwaretest bezeichnet in der Informatik ein mögliches Verfahren zur teilweisen Verifikation und Validierung eines Programms. Der Test dient der Qualitätssicherung einer neuen oder geänderten Software. Hierbei ist das Ziel das reelle Verhalten mit Hilfe von Testfällen zu untersuchen und mit den erwarteten Ergebnissen zu vergleichen und zu dokumentieren. Hierbei geht es um eine Aktivität der Softwareentwicklung. Natürlich gibt es nicht nur eine Art von Test mit der man alle Problemstellungen abdecken kann. Name Beschreibung Application-Level-Test Test der gesamten Anwendung aus Benutzersicht in einer Testumgebung. (Öffentlicher) Betatest Testen einer Anwendung in produktiver Umgebung. Performance-Test Testet das Verhalten der Anwendung unter verschiedener Last (etwa Antwortzeiten, Speicherverbrauch). Skalierbarkeits-Test Ähnlich dem Performance-Test, mit Schwerpunkt auf Veränderung der Leistung und Ressourcenbeanspruchung bei der Variation einzelner Parameter (zum Beispiel Zugriffe auf eine Datenbank). Unit-Test Test der Bausteine einer Software (je nach Programmiersprache zum Beispiel Klassen oder Unterprogramme). White-Box-Test Testen von Code durch möglichst umfassend abgedeckte Parameterbereiche mit dem Ziel, potenzielle Laufzeitfehler zu ermitteln (White-Box, da Kenntnisse der internen Struktur für die Parametererzeugung genutzt werden). Black-Box-Test Testen von Code-Einheiten über spezielle Testfälle. Die Grenze zum White-Box-Test ist fließend, aber es steht mehr die richtige Verarbeitung von Eingaben im Ronny Boost

5 Mittelpunkt, weniger das Auffinden von Laufzeitfehlern. Regression-Test Vergleich von Testläufen vor und nach der Änderung von Code. Ergebnisse sollten sich nur geplant (etwa als Folge eines Bugfixes) ändern. Integration-Test Bezeichnet eine aufeinander abgestimmte Reihe von Einzeltests, die dazu dient, welche dazu dient das Zusammenspiel mehrerer von einander abhängiger Komponenten zu testen. Tabelle 2-1: Zusammenfassung verschiedener Testmethoden. 2.1 Unit-Test Unit-Tests sind Teil einer Softwareentwicklungsvorgehensweise, wie zum Beispiel Extreme Programming. Mit ihrer Hilfe überprüft man die Korrektheit von Modulen einer Software. Ein wichtiges Anwendungsgebiet ist an dieser Stelle das Refactoring. Bei Refactoring handelt es sich um das Ziel Quellcode lesbarer zu machen. Um dabei die Funktionalität im vollem Umfang weiterhin gewährleisten zu können verwendet man Unit-Tests. Des Weiteren ist es ein integraler Bestandteil bei der testgetriebenen Programmierung. Hier werden die Testfälle meist vor oder während der eigentlichen Entwicklung der Software geschrieben und gewartet. Dadurch wird ermöglicht, dass Tests automatisiert und reproduzierbar wiederholt werden können. Mit Hilfe von Unit-Tests ist eine unmittelbare Rückmeldung für den Programmierer möglich, ob das Programm den gewünschten Anforderungen entspricht und korrekte Ergebnisse produziert oder nicht. Komponententests sind ein essentieller Bestandteil der Qualitätssicherung und Softwareentwicklung. Unit-Tests sind eine sehr geeignete Vorstufe zu Integrationstests, welche wiederum dafür geeignet sind um eine Summe von mehreren Klassen in Abhängigkeit von einander zu testen. Jedoch werden diese Integrationstests meist manuell durchgeführt. Ronny Boost

6 2.2 Integrationstest Da Software nur in den seltensten Fällen aus nur einer Methode besteht, ist es nötig diese in Kombination miteinander zu testen um zu überprüfen, ob diese im Zusammenspiel miteinander auch korrekt arbeiten. Hierfür werden Testszenarios definiert, welche in der Lage sind nachzuweisen, dass die zwei oder mehr Methoden korrekt und gemäß den Spezifikationen miteinander agieren. Als Methoden werden hierfür meist Funktions- und Schnittstellentests verwendet. Da die Funktionstests meist schon in den Unit-Tests verwendet werden, dienen sie an dieser Stelle zum Überprüfen, ob die korrekten Komponenten verwendet werden. Die Schnittstellentests werden wiederum dazu verwendet zum Überprüfen, ob zwischen Komponenten verwendete Daten richtig sind. Integrationstests sind jedoch nicht auf das Gesamtsystem festgelegt. Da mit der Größe der Software auch der Testaufwand überproportional steigt, wird die Software meist in einzelne Untersysteme eingeteilt, die einzeln getestet werden, welche im Gesamtsystem auch wiederum nur als Komponente gesehen werden. 2.3 Blackbox-Test Dabei betrachtet der Tester das Programm als Blackbox, d.h. der Tester ist nicht an dem internen Verhalten und an der Struktur des Programms interessiert, sondern daran, Umstände zu entdecken, bei denen sich das Programm nicht gemäß den Anforderungen verhält. Die Testdaten werden nur aus der Spezifikation (Aus-/Eingabeparameter sowie die Funktion des Programms) abgeleitet, d.h. ohne spezielle Kenntnis der internen Struktur. Äquivalenzklassen Wie oben hergeleitet soll hier die Untermenge von Testfällen bestimmt werden, die mit höchster Wahrscheinlichkeit Fehler enthält. Zur Bestimmung dieser Untermenge sollte man wissen, dass ein gut ausgewählter Testfall zwei weitere Eigenschaften haben sollte: Ronny Boost

7 er reduziert die Anzahl anderer Testfälle, die man entwickeln müsste um ein vorgegebenes Ziel beim Testen zu erreichen er überdeckt eine große Menge anderer möglicher Testfälle, d.h. er sagt etwas über die An- oder Abwesenheit von Fehlern für diesen speziellen Satz von Eingabedaten aus Letzteres bedeutet, wenn ein Testfall in einer Äquivalenzklasse einen Fehler entdeckt, so erwartet man, dass alle anderen Testfälle in einer Äquivalenzklasse den gleichen Fehler finden. Anders herum ausgedrückt, wenn ein Testfall den Fehler nicht entdeckte, so erwarten wir, dass kein anderer Testfall in der Äquivalenzklasse diesen Fehler findet. Diese beiden Überlegungen führen zu einer Blackbox-Strategie, die als Äquivalenzklassenbildung bekannt ist. Die zweite Bedingung dient zur Entwicklung einer Menge von Bedingungen, die getestet werden sollen. Mit der ersten Überlegung wird dann ein Minimalsatz von Testfällen definiert, der diese Bedingungen vollständig erfasst. 2.4 Whitebox-Test Die interne Struktur des Programms ist beim Whitebox-Test zentraler Dreh und Angelpunkt der Untersuchung. Bei dieser Strategie definiert der Tester die Testdaten mit Kenntnis der Programmlogik. Beim Whitebox-Testen betrachtet man den Anteil des Programms (source code), der durch die Testfälle ausgeführt oder angesprochen wird. Hierzu dienen folgende Strategien [7]: Line coverage (Ausführung aller Anweisungen) Hier soll jede Anweisung im Programm wenigstens einmal ausgeführt werden. Das Verhältnis von ausgeführten zu vorhandenen Anweisungen wird als C0- Überdeckung bezeichnet. Bei 100% C0-Überdeckung führen die Testfälle jede Anweisung mindestens einmal aus. Decision oder branch coverage Dies ist eine strengere Strategie für die Erfassung der Logik, bei der alle Entscheidungen oder Sprünge ausgeführt werden. Bei diesem Verfahren Ronny Boost

8 müssen hinreichend viele Testfälle entworfen werden, so dass bei jeder Entscheidung sowohl der THEN-Zweig als auch der ELSE-Zweig mindestens einmal durchlaufen wird. Das Verhältnis von ausgeführten zu vorhandenen Entscheidungspfaden (z.b. IF/ELSE-Zweige) wird als C1-Überdeckung bezeichnet. Bei 100% C1-Überdeckung liefert jede Entscheidung mindestens einmal TRUE und einmal FALSE. Man kann zeigen, dass diese Strategie auch die Forderung nach der Ausführung eines jeden Befehls erfüllt. 2.5 Zusammenfassung All diese Testverfahren sind in der Theorie sehr schön, jedoch werden sie nur zu einem geringen Teil in der Praxis so eingesetzt. Am praktikabelsten bei diesen Methoden sind die Komponenten- und Integrationstests. Sie sind am einfachsten zu realisieren, sie sind kombinierbar, reproduzierbar und es gibt viele Hilfsprogramme, die einem die Arbeit erleichtern können. In Java heißt hier das Zauberwort JUnit. Ronny Boost

9 3 Testen mit JUnit Nun ist blindes Drauflostesten vielleicht nicht besonders klug. Darum stellt sich die Frage nach sinnvollen Kriterien für Softwaretests. Gute Deklarationen liefert die Literaturrecherche [8]: Strikte Trennung des Testcodes vom Programmcode gewährleistet schlanke Klassen und kleinere Softwarepakete zur Auslieferung. Testfälle sind vollkommen unabhängig voneinander ausführbar. Es gibt keine festgelegte Reihenfolge oder Abhängigkeiten der Testfälle untereinander. Das Ergebnis der Tests ist auf einen Blick eindeutig erkennbar, dadurch ist keine Auswertung von Logfiles oder kryptischer Konsolenausgaben notwendig. 3.1 JUnit JUnit ist ein frei verfügbares, unter der IBM Public License stehendes Framework für die Durchführung von Black-Box-Tests. Testfälle werden in eigenen Testklassen kodiert und zu Testsuiten zusammengefasst. Somit ist die strikte Trennung des Codes von Anwendung und Test sichergestellt. Diese Tatsache beinhaltet folgende Vorteile: Bei Auslieferung der Software werden die Tests nicht mit ausgeliefert und somit ist das Programm schlanker. Weitere, nicht mit der Anwendung vertraute Entwickler, können sich schneller einarbeiten. Der Code der Anwendung bleibt selbst bei steigender Komplexität übersichtlich. Die grundlegende Einheit beim Testen mit JUnit ist der Testfall - in der Klasse TestCase gekapselt. Ergebnisse werden in TestResult gespeichert. Die zentrale Methode der Klasse TestCase ist TestCase.runTest(TestResult), die im Interface Test definiert wird. Zum Aufbau dieser Methode später mehr. Mehrere Testfälle Ronny Boost

10 werden zu Gruppen in der Klasse TestSuite zusammengefasst. Das Besondere an TestSuite ist, dass sie ebenfalls das Interface Test implementiert. Wird dann TestSuite.runTest(TestResult) aufgerufen, gibt die Klasse den Aufruf an alle enthaltenen Testfälle weiter. Das funktioniert auch, falls eine Testsuite nicht nur echte Testcases enthält, sondern wieder Testsuiten. So ist das hierarchische Schachteln von Testfällen möglich. In Abbildung 3.1 ist das Klassenschema zu sehen. Das Design-Pattern, welches das Test -Interface und die beiden Klassen TestCase und TestSuite verbindet, heißt Composite. Wie in der Abbildung zu sehen, ist das Framework mit drei zentralen Klassen und einem Interface sehr übersichtlich, was die Einarbeitung verkürzt und den Einsatz vereinfacht. Die gesamte Distribution hat zwar momentan elf Klassen und drei Interfaces, aber von den zusätzlichen Klassen ist nur die Assert -Klasse von ähnlich zentraler Bedeutung (und auch sie nur indirekt). Abbildung 3.1: Aufbau der wichtigsten Klassen des JUnit-Frameworks [2] Die Klasse Assert mit den wichtigsten Asserts: class Assert (parent class of TestCase) - static asserttrue() basic assert function (used to be assert()) Ronny Boost

11 - static assertequals() for all primitive types and Object - static assertnull() for Object - static assertnotnull() for Object - static assertsame() for Object - static assertnotsame() for Object - static assertfalse() for boolean condition - static fail() make a test fail Zurück zum Aufbau der Runtest-Methode. Sie ruft intern die folgenden drei Methoden auf: setup() runtest() teardown() Alle drei Methoden sind leer implementiert und können vom Entwickler überschrieben werden. setup() und teardown() erzeugen eine geeignete Testumgebung beziehungsweise geben sie frei. Die Methode runtest() dagegen enthält die eigentlichen Tests. Durch Reflection - eine Java-Technik, die es ermöglicht, zur Laufzeit die Methoden einer Klasse abzufragen - ist es möglich in der Testklasse nur eine Reihe von Methoden nach dem Schema void testxxx() anzulegen statt runtest() zu überschreiben. Durch den Konstruktor TestSuite(MyTestClass.class) werden dann automatisch alle Testmethoden innerhalb der Testsuite durchgeführt. Die Reihenfolge der Ausführung der test Methoden ist dabei nicht festgelegt und spielt insofern keine Rolle, da die Methoden der Anwendung unabhängig voneinander das gleiche Ergebnis liefern sollen. Ronny Boost

12 3.2 Installation Die Installation ist einfach: das heruntergeladene Zip-File entpacken (Download von und das dann verfügbare Jar-Archiv zum CLASSPATH des jeweiligen Systems hinzufügen bzw. in die IDE einbinden. 3.3 Beispiel für einen Test Im folgenden Listing ist ein Beispiel zum Anlegen von Person Objekten zu sehen: Listing 1: Person.java 01: class Person { 02: private String ivname, inname; 03: 04: public Person(String v, String n) { 05: ivname = v; 06: inname = n; 07: } 08: 09: public boolean equals(object o) { 10: Person p = (Person) o; 11: return p.getvname() == ivname && p.getnname() == inname; 12: } 13: 14: public String getvname() { 15: return ivname; 16: } 17: 18: 19: public String getnname() { 20: return inname; 21: } 22: 23: public void setvname(string v) { 24: inname = v; 25: } 26: 27: 28: public void setnname(string n) { 29: inname = n; 30: } 31: 32: public String tostring() { 33: return ivname + " " + inname; 34: } 35: } Die Objekte der Klasse Person.java enthalten die - Attribute: Ronny Boost

13 o ivname = Vorname. o inname = Nachname. - Methoden: o Getter und Setter für die Attribute. o tostring(), um aus Vor- und Nachname den vollständigen Namen zusammenzusetzen. und den Konstruktor, welchem alle o.g. Attribute übergeben werden. Zum Testen der Methoden des Anwendungscodes dient die Klasse PersonTest.java. Listing 2: PersonTest.java 01: import junit.framework.*; 02: 03: public class PersonTest extends TestCase { 04: 05: private Person iauthor,iauthor2, iauthor3, itux, itux2; 06: private String iname; 07: 08: public PersonTest(String name) { 09: super(name); 10: } 11: 12: public static void main(string[] args) { 13: junit.swingui.testrunner.run(persontest.class); 14: } 15: 16: protected void setup() { 17: iauthor = new Person("Bernhard", "Bablok"); 18: iauthor2 = new Person("Bernhard", "Bablok"); 19: iauthor3 = new Person(null,null); 20: iauthor3.setvname("bernhard"); 21: iauthor3.setnname("bablok"); 22: itux = new Person("Tux",null); 23: itux2 = new Person("Tux",null); 24: iname = "Penguin"; 25: } 26: 27: public void testequals() { 28: asserttrue(iauthor.equals(iauthor2)); 29: asserttrue(!iauthor.equals(iname)); 30: asserttrue(itux.equals(itux2)); 31: } 32: 33: public void testsetname() { 34: assertequals(iauthor,iauthor3); 35: } 36: 37: public void testgetnname() { 38: assertequals(iauthor.getnname(),"bablok"); 39: } 40: 41: public void testtostring() { 42: assertequals(iauthor.tostring(), "Bernhard Bablok"); 43: } Ronny Boost

14 44: }. Das Test im Namen ist nicht zwingend erforderlich, aber um die eindeutige Zugehörigkeit zur zu testenden Klasse sicher zu stellen ist es sinnvoll hinter den ursprünglichen Klassennamen der Anwendung das Suffix Test anzuhängen. Im Gegensatz hierzu ist die Benennung der Prüfmethoden fest vorgegeben: Diese müssen immer der Form testxxx () entsprechen, wobei für XXX ein beliebiger Name stehen kann, wiederum vorzugsweise der Name der zu testenden Methode. Der Ablauf des Test beginnt durch den Aufruf der main( )-Methode und des darin enthaltenen Methodenaufrufs von run( ) wie oben beschrieben. In der Methode setup() wird eine Testumgebung mit diversen Testobjekten angelegt. Auf diesen Testobjekten werden nun die Testmethoden ausgeführt. Sobald ein assert( ) fehlschlägt unterbricht JUnit die Ausführung und signalisiert dies mit einem roten Balken und der Angabe bei welchem Test dies passierte. Hier beispielsweise schlägt der Test fehl. Der hier verwendete TestRunner zeigt die in Abbildung 3.2 dargestellte Ausgabe: Abbildung 3.2 JUnit in Aktion: Zwei Fehler wurden gefunden, in der unteren Hälfte der Stack Trace dazu. [2] Ronny Boost

15 Nach Bereinigung aller Fehler sieht das Ergebnis wie in Abbildung 3.3 aus: Abbildung 3.3: Ein erfolgreicher JUnit-Lauf. [2] Es dient also ein einfacher grüner oder roter Balken als Bestätigung für den Erfolg bzw. Misserfolg des Testvorgangs. Um nun diese Tests in einer TestSuite zu integrieren ist nicht mehr viel Aufwand vonnöten: Listing 3: AllTests.java 01: import junit.framework.*; 02: 03: public class AllTests { 04: 05: public static Test suite() { 06: TestSuite suite = new TestSuite("Test for default package"); 07: suite.addtestsuite(persontest.class); 08: return suite; 09: } 10: } 3.4 Test Driven Development In obigem Beispiel wurde der Test erst nach Erstellen der Klasse Person.java für die darin enthaltenen Programmteile implementiert. Eine andere Vorgehensweise wäre die Überlegung der Test-First-Strategie. Dabei gilt es einen Test für eine Ronny Boost

16 Softwarekomponente - bei der objektorientierten Programmierung in der Regel Klassen - vor der eigentlichen Komponente zu implementieren. Der Entwickler einer Klasse ist sich in der Regel klar darüber, was er mit seiner Klasse erreichen möchte. So entsteht eine Art Protokoll für die Anwendung der Klasse. Und genau dieses Protokoll wird von einem Unit Test geprüft. Die zu entwickelnde und zu testende Klasse wird dabei immer nur so weit ausprogrammiert, wie es notwendig ist, um einen Test zu erfüllen. Nach jedem erfolgreichen Test wird dann der entwickelte Code in kurzen Zyklen weiter verfeinert und erneut getestet, bis dieser die Geschäftslogik erfüllt und in einem optimalen Zustand ist. Neudeutsch spricht man hier von Refactoring. Der Vorteil dieses Verfahrens ist es, stets über einen funktionierenden Code zu verfügen, der leicht automatisiert getestet werden kann. In der testgetriebenen Softwareentwicklung geht der Entwickler folgendermaßen vor: - Der erste Schritt ist das Schreiben eines Tests für die zu erfüllende Teilfunktion - Der Code der Anwendung wird nun so geschrieben, um dem Test zu genügen oder anders ausgedrückt: damit der Test fehlerfrei durchläuft. - Während der Implementierung wird nun abwechselnd am Programm- bzw. Testcode geschrieben, wodurch kleine Iterationen entstehen, welche in sehr kurzen Zeitabständen (5 20 Minuten) erfolgen. - Bevor der neu entstandene Code in das Gesamtsystem integriert werden darf, müssen alle Tests fehlerfrei laufen. Die hierbei immer wieder auftretende Reihenfolge beim Testen ist grün rot grün rot, d.h. nach Schreiben des Tests kann dieser selbstverständlich noch nicht erfüllt werden, da noch kein Code zum Erfüllen der Testbedingung vorhanden ist. Nun schreibt der Entwickler so wenig Code wie möglich, um den Test zu erfüllen bis der JUnit-Test als Ergebnis den oben erläuterten grünen Balken ausgibt. Dann beginnt der Ablauf von vorne mit dem Schreiben eines Tests. Der bis dahin geschriebene Programmcode wird durch diese kleinen Iterationen mit verfeinert und bei jedem Ausführen der Tests wieder geprüft. Dadurch wird sichergestellt, bereits positiv getesteten Code nicht wieder zu verschlechtern. Ronny Boost

17 3.4.1 Vorteile des TDD Das TDD zwingt den Entwickler dazu, sich während der Entwicklung einer Klasse und speziell noch vor der Implementierung Gedanken über die Nutzung der Klasse zu machen. Fehler in der Implementierung werden frühzeitig vermieden oder erkannt, was bei der abschließenden Fehlersuche enorm Zeit und damit Geld einspart. Ist die Software allerdings im fortgeschrittenen Zustand, ist der Fehler nur unter großem Aufwand (also teuer) zu beheben. Code soll funktional bleiben, also nicht regressiven Einflüssen während der weiteren Entwicklung unterliegen. Kein unnötiger Code im Programm Nachteile des TDD Es sind gute bis sehr gute Kenntnisse im Entwerfen und Implementieren von Software zwingend erforderlich. Ohne Disziplin kein Erfolg. Weicht der Entwickler von der Vorgehensweise der kleinen Iterationen ab schreibt beispielsweise der Entwickler in einer kreativen Phase drei Klassen ohne vorher Tests zu schreiben ist die Methodik sehr schwer wieder aufzunehmen. Ronny Boost

18 3.5 Konventionelle Softwareerstellung vs. TDD Eine Gegenüberstellung von konventioneller Entwicklung in Abbildung 3.4 zu testgetriebener Entwicklung in Abbildung 3.5 soll die Vorteile des Testcase Driven Development (TDD) bezüglich Aufwand, Kosten und umgesetzter Anforderungen verdeutlichen: Abbildung 3.4: Konventioneller Projektablauf [3] Abbildung 3.5: Testgetriebener Projektablauf [3] Ronny Boost

19 4 Zusammenfassung JUnit eignet sich gut für nachvollziehbare, reproduzierbare Tests von abgeschlossenen Einheiten (Units). Dadurch ist Refactoring des bereits implementierten Codes begünstigt. Die prinzipielle Einfachheit mit der Tests umgesetzt werden können, kombiniert mit beliebiger Erweiterbarkeit entsprechend dem Wachstum des Programms ist die große Stärke von JUnit. Es ist allerdings nicht das ultimative Werkzeug zur Behebung aller Fehler in Software und deren Entwicklung, sondern stellt ein wichtiges zusätzliches Mittel, insbesondere für die testgetriebene Softwareentwicklung und teilweisen Validierung bereits vorhandener Projekte dar. Im Hinblick auf das TDD sollte sich jeder Programmierer ernsthafte Gedanken über seine Vorgehensweise beim Programmieren anstellen. Der Weg vom Drauflosprogrammieren zum strukturierten Vorgehen mittels Entwurf der wirklich benötigten Funktionen vor dem ersten Zeichen Code ist ein Steiniger, aber Lohnenswerter. Ronny Boost

20 5 JUnit Erweiterungen Projekt Beschreibung StrutsTestCase Testen des JSP-Frameworks Struts. JUnitX und XPTest Erweiterung auf Privat- und Protected-Klassen, Integration in Together. JUnit und TIBCO Integration in TIBCO Active Enterprise Application. JUnit Test Generator Generierung von Testfällen. Daedalus JUnit Extensions Ressourcen-Management für JUnit-Tests. JFCUnit Unit-Tests für Swing-Applikationen. JUnitPP Unter anderem Testdaten Repository, Kommandozeilen-Argumente. JSP TEST Testen von Java Server Pages. JXUnit Trennt Testdaten und Testcode. Verwendet XML. JUnitHelp Hilfe zu JUnit. Joshua Regression-Testing mit JUnit. JDepend Testen von Design-Metriken (misst die Komplexität der Klassen). JesTer Sucht Code, der nicht durch Tests abgedeckt wird. HttpUnit Funktionstest von interaktiven, dynamischen Webseiten. JUnitEE Tests für J2EE-Anwendungen. Cactus Testet Server-seitigen Java-Code. UnitPerf Erweitert JUnit-Testklassen für Performance- und Skalierungstests. Tabelle 5-1: JUnit Erweiterungen. Ronny Boost

21 6 Abbildungsverzeichnis Tabelle 2-1: Zusammenfassung verschiedener Testmethoden. 5 Abbildung 3.1: Aufbau der wichtigsten Klassen des JUnit-Frameworks [2] 10 Abbildung 3.2 JUnit in Aktion: Zwei Fehler wurden gefunden, in der unteren Hälfte der Stack Trace dazu. [2] 14 Abbildung 3.3: Ein erfolgreicher JUnit-Lauf. [2] 15 Abbildung 3.4: Konventioneller Projektablauf [3] 18 Abbildung 3.5: Testgetriebener Projektablauf [3] 18 Tabelle 5-1: JUnit Erweiterungen. 20 Ronny Boost

22 7 Quellen [1] Frank Westphal Testgetriebene Entwicklung 2005 [2] Bernhard Bablok Reihenuntersuchung ; Linux-Magazin Ausgabe 03/2002 [3] [4] de.wikipedia.org [5] Das heilige Orakel [6] Robert Pintarelli Modul-Tests mit JUnit 2004 [7] Christian Aich, Robert Reeb Einführung in den Softwaretest 2004 [8] Barbara Beenen Rot-Grünes Wechselspiel 2004 Ronny Boost

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept Testkonzept 1.Einführung Um die Zuverläsigkeit und die Qualität der Software und des gesamten Systems zu verbessern, sind Tests durchzuführen. Die Testreihe läst sich in drei Stufen einteilen, nülich Komponententest,

Mehr

Das Test-Framework JUnit ETIS SS04

Das Test-Framework JUnit ETIS SS04 Das Test-Framework JUnit ETIS SS04 Gliederung Motivation TestFirst Grundlagen Assert TestCase Lebenszyklus TestCase UML-Diagramm TestCase TestSuite Zusammenfassung 2 Motivation (I) Kostspielige Folgen

Mehr

JUnit. Software-Tests

JUnit. Software-Tests JUnit Software-Tests Übersicht Einleitung JUnit Jia Li Grundlegendes Diana Howey Hendrik Kohrs Praktische Einbindung Benjamin Koch Zili Ye Einleitung in allgemeines Testen Automatische Tests Testen ist

Mehr

Testen mit JUnit. Motivation

Testen mit JUnit. Motivation Test First Design for Test in Eclipse (eigentlich: ) zu einer Klasse Beispiel zur Demonstration Ergänzungen Test First "Immer dann, wenn Du in Versuchung kommst, etwas wie eine print- Anweisung oder einen

Mehr

JUnit - Test Driven Development. Bernhard Frey, Thorsten Stratmann, Jackson Takam, Michel Müller 1

JUnit - Test Driven Development. Bernhard Frey, Thorsten Stratmann, Jackson Takam, Michel Müller 1 JUnit - Test Driven Development Bernhard Frey, Thorsten Stratmann, Jackson Takam, Michel Müller 1 Gliederung 1.Einleitung 1.1 Geschichte 1.2 Was sind Unit-Tests? 1.3 Failures/Errors 1.4 Ziele und Nutzen

Mehr

Software - Testung ETIS SS05

Software - Testung ETIS SS05 Software - Testung ETIS SS05 Gliederung Motivation Was ist gute Software? Vorurteile gegenüber Testen Testen (Guidelines + Prinzipien) Testarten Unit Tests Automatisierte Tests Anforderungen an Testframeworks

Mehr

Unit Tests in der Testgetriebenen Entwicklung

Unit Tests in der Testgetriebenen Entwicklung Unit Tests in der Testgetriebenen Entwicklung Reduzierung des Testanteils am Gesamtsoftwareentwicklungsaufwand -- neue Strategien und Tools -- Hauptseminar Systemorientierte Informatik Christian Krauß

Mehr

Programmiertechnik II

Programmiertechnik II Modultests Ziele Überprüfung der Korrektheit eines Moduls Korrektheit: Übereinstimmung mit (informaler) Spezifikation Modul: kleine testbare Einheit (Funktion, Klasse) Engl.: unit test White box testing

Mehr

Testen mit JUnit. Apcon Workplace Solutions Member of itelligence. Testen von Java-Code mit JUnit. ÿstruktur eines Testfalls

Testen mit JUnit. Apcon Workplace Solutions Member of itelligence. Testen von Java-Code mit JUnit. ÿstruktur eines Testfalls Testen von Java-Code mit JUnit ÿmotivation ÿjunit-testklassen ÿjunit-testfälle ÿstruktur eines Testfalls Henning Wolf APCON Workplace Solutions GmbH wolf@jwam.de Motivation: Werkzeugunterstützung für Tests

Mehr

Fortgeschrittenes Programmieren mit Java. Test Driven Development

Fortgeschrittenes Programmieren mit Java. Test Driven Development Fortgeschrittenes Programmieren mit Java Test Driven Development Test getriebene Programmierung Benedikt Boeck Hochschule für Angewandte Wissenschaften Hamburg 6. November 2009 B. Boeck (HAW Hamburg) Test

Mehr

Unit Tests. Programmiermethodik. Eva Zangerle Universität Innsbruck

Unit Tests. Programmiermethodik. Eva Zangerle Universität Innsbruck Unit Tests Programmiermethodik Eva Zangerle Universität Innsbruck Überblick Einführung Java Ein erster Überblick Objektorientierung Vererbung und Polymorphismus Ausnahmebehandlung Pakete und Javadoc Spezielle

Mehr

Unit Testing mit JUnit. Dr. Andreas Schroeder

Unit Testing mit JUnit. Dr. Andreas Schroeder Unit Testing mit JUnit Dr. Andreas Schroeder Überblick Was dieses Video behandelt Warum Testen? Was sind Unit Tests? Der Teufelskreis des Nicht-Testens JUnit Unit Test Vorteile Test-Inspiration Wann aufhören?

Mehr

Unit Tests mit Junit 4. Dario Borchers

Unit Tests mit Junit 4. Dario Borchers Unit Tests mit Junit 4 Dario Borchers Agenda Warum testgetriebene Entwicklung von Software? - Motivation Was ist testgetriebene Entwicklung? - Prozess der testgetriebenen Entwicklung - Arten von Tests

Mehr

Programmieren I. Übersicht. Vorlesung 12. Handout S. 1. Martin Schultheiß. Hochschule Darmstadt Wintersemester 2010/2011

Programmieren I. Übersicht. Vorlesung 12. Handout S. 1. Martin Schultheiß. Hochschule Darmstadt Wintersemester 2010/2011 Programmieren I Martin Schultheiß Hochschule Darmstadt Wintersemester 2010/2011 1 2 Übersicht Testen ist eine der wichtigsten, aber auch eine der Zeitaufwändigsten Arbeitsschritte der Softwareentwicklung.

Mehr

Testgetriebene Entwicklung mit JUnit4

Testgetriebene Entwicklung mit JUnit4 Testgetriebene Entwicklung mit JUnit4 Seminarvortrag im Fach Fortgeschrittenes Programmieren in Java, Dozent: Prof. Klinker Datum: 30.04.2010 Referent: Marius Schmeding Ausgangsfragen... Wie testet man

Mehr

Komponententest. Testen von Software Systemen. Übung 02 SS 2009 Version: 1.0 09.06.2009

Komponententest. Testen von Software Systemen. Übung 02 SS 2009 Version: 1.0 09.06.2009 Testen von Software Systemen Übung 02 SS 2009 Version: 1.0 09.06.2009 Komponententest Kunde: Dr. Reinhold Plösch Dr. Johannes Sametinger Kundenreferenz: 259.019 Team 19 Mitarbeiter: Christian Märzinger

Mehr

Unit-Test Theorie und Praxis. Stephan Seefeld, INGTES AG

Unit-Test Theorie und Praxis. Stephan Seefeld, INGTES AG Unit-Test Theorie und Praxis Stephan Seefeld, INGTES AG Inhalt Was sind Unit-Test? NUnit für.net Demo Seite 2 Quellen Für diesen Vortrag verwendete Quellen: dotnet User Group Berlin Brandenburg http://www.dotnet-berlinbrandenburg.de/

Mehr

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R Vector Software W H I T E P A P E R Test Automation mit VectorCAST während der gesamten Softwareentwicklung VectorCAST Produktfamilie Die VectorCAST Produktfamilie automatisiert Testaktivitäten über den

Mehr

Thema: Testen von objektorientierter Software

Thema: Testen von objektorientierter Software Seminar Simulation und Bildanalyse mit Java Thema: Testen von objektorientierter Software Uta Dienst 1. Teil: Einführung in den Software-Test 2. Teil: JUnit-Einführung Uta Dienst 17.11.2003 2 1. Teil:

Mehr

Test-Driven Design: Ein einfaches Beispiel

Test-Driven Design: Ein einfaches Beispiel Test-Driven Design: Ein einfaches Beispiel Martin Wirsing in Zusammenarbeit mit Moritz Hammer und Axel Rauschmayer SS 06 2 Ziele Veranschaulichung der Technik des Test-Driven Design am Beispiel eines Programms

Mehr

Testen mit JUnit. Martin Wirsing. Ziele. in Zusammenarbeit mit Michael Barth, Philipp Meier und Gefei Zhang

Testen mit JUnit. Martin Wirsing. Ziele. in Zusammenarbeit mit Michael Barth, Philipp Meier und Gefei Zhang Testen mit JUnit Martin Wirsing in Zusammenarbeit mit Michael Barth, Philipp Meier und Gefei Zhang 12/04 2 Ziele Lernen Unit Tests zu schreiben Lernen mit Unit-Testen mit JUnit durchzuführen 3 Testen Da

Mehr

Java Schulung. Objektorientierte Programmierung in Java Teil IV: Testen mit JUnit. Prof. Dr. Nikolaus Wulff

Java Schulung. Objektorientierte Programmierung in Java Teil IV: Testen mit JUnit. Prof. Dr. Nikolaus Wulff Java Schulung Objektorientierte Programmierung in Java Teil IV: Testen mit JUnit Prof. Dr. Nikolaus Wulff JUnit JUnit ist das Opensource Testframework. Es existieren Portierungen für fast alle objektorientierten

Mehr

Unit Testing, SUnit & You

Unit Testing, SUnit & You HUMBOLDT-UNIVERSITÄT ZU BERLIN MENSCH-TECHNIK-INTERAKTION ARBEITSGRUPPE SOFTWARETECHNIK (INSTITUT FÜR INFORMATIK) ARBEITSGRUPPE INGENEURPSYCHOLOGIE (INSTITUT FÜR PSYCHOLOGIE) Unit Testing, SUnit & You

Mehr

Unit Tests und Fehlersuche

Unit Tests und Fehlersuche Unit Tests und Fehlersuche SE 1 - Softwareentwicklungspraktikum Test Deadline! Sinnvolle Tests kompilierbar im CVS d.h. Schnittstellen zu Strategiemethoden etc. schon erstellen Kommentieren! Besser ein

Mehr

am Beispiel von JUnit

am Beispiel von JUnit Aufbau eines Testwerkzeugs am Beispiel von JUnit Üblicher Ansatz für Tests und Fehlersuche: Print-Befehle, Debugger-Ausdrücke, Test-Skripte möglichst über globale Variable debug steuerbar Command Pattern

Mehr

Software-Engineering Software-Management

Software-Engineering Software-Management Software-Engineering Software-Management 12.3 Unit-Tests mit JUnit - Wissen, was der Sourcecode macht! Lösung Prof. Dr. Rolf Dornberger Software-Engineering: 12.3 Unit-Tests mit JUnit 30.04.2006 1 12.3

Mehr

Software Engineering in der Praxis

Software Engineering in der Praxis Software Engineering in der Praxis Praktische Übungen Dirk Wischermann Marc Spisländer Lehrstuhl für Software Engineering Friedrich-Alexander-Universität Erlangen-Nürnberg 18. Dezember 2006 Inhalt Nachlese

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Software Engineering Klassendiagramme Assoziationen

Software Engineering Klassendiagramme Assoziationen Software Engineering Klassendiagramme Assoziationen Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Lesen von Multiplizitäten (1) Multiplizitäten werden folgendermaßen

Mehr

Testen von graphischen Benutzeroberflächen. 26. Juni 2013

Testen von graphischen Benutzeroberflächen. 26. Juni 2013 Testen von graphischen Benutzeroberflächen 26. Juni 2013 Überblick Testarten Methoden-, Klassen-, Komponenten-, Systemtests Motivation für automatisches Testen von graphischen Benutzeroberflächen Entwicklungsprinzipien

Mehr

Programmierung 2 Studiengang MI / WI

Programmierung 2 Studiengang MI / WI Programmierung 2 Studiengang MI / WI Dipl.-Inf., Dipl.-Ing. (FH) Michael Wilhelm Hochschule Harz FB Automatisierung und Informatik mwilhelm@hs-harz.de Raum 2.202 Tel. 03943 / 659 338 FB Automatisierung

Mehr

Testphase. Das Testen

Testphase. Das Testen Testphase VIS Projekt Freie Universität Berlin N.Ardet - 17.4.2001 Das Testen Testen ist das Ausführen eines Software- (Teil)systems in einer definierten Umgebung und das Vergleichen der erzielten mit

Mehr

Testen von graphischen Benutzeroberflächen. 24. Juni 2015

Testen von graphischen Benutzeroberflächen. 24. Juni 2015 Testen von graphischen Benutzeroberflächen 24. Juni 2015 Überblick Motivation für das automatische Testen von graphischen Benutzeroberflächen Entwicklungsprinzipien für GUIs Capture / Replay Testmethode

Mehr

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim Test- Grundsätzliches - - - Ablauf von Tests Grundsätzliche Test- -Tests Äquivalenzklassenbildung Randwertanalyse -Tests Man unterscheidet verschiedene Überdeckungsgrade: Statement Coverage Decision Coverage,

Mehr

Das automatisierte Testen mit JUnit

Das automatisierte Testen mit JUnit Das automatisierte Testen mit JUnit SWT Seminar (SS03) Ausgearbeitet von Sundui Baatarjav Am Fachbereich Informatik der TU-Berlin EINLEITUNG 3 JUNIT - FRAMEWORK 4 Aufbau und Struktur 4 TestCase 4 Assert

Mehr

Testen Prinzipien und Methoden

Testen Prinzipien und Methoden Testen Prinzipien und Methoden ALP 2 SS2002 4.7.2002 Natalie Ardet Definition Im folgenden gilt: Software = Programm + Daten + Dokumentation Motivation Software wird immer mehr in Bereichen eingesetzt,

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Test-Driven Developement Eine Einführung

Test-Driven Developement Eine Einführung Test-Driven Developement Eine Einführung 2007 by Tobias Hagen Im Rahmen der Veranstaltung Aktuelle Themen der Informatik bei Prof. Dr. Friedbert Kaspar Hochschule Furtwangen University Übersicht Einführung...

Mehr

Whitebox-Tests: Allgemeines

Whitebox-Tests: Allgemeines -Tests: Allgemeines Andere Bezeichnungen Logic driven, Strukturelles Der Tester entwickelt Testfälle aus einer Betrachtung der Ablauflogik des Programms unter Berücksichtigung der Spezifikation Intuitiv

Mehr

Systematisches Testen der Funktionalität von Softwaresystemen. 17. Juni 2015

Systematisches Testen der Funktionalität von Softwaresystemen. 17. Juni 2015 Systematisches Testen der Funktionalität von Softwaresystemen 17. Juni 2015 Überblick Semantische Qualität von Software Teststrategien und prinzipien Testgetriebene Softwareentwicklung Welche Arten von

Mehr

Testgetriebene Webentwicklung mit PHPUnit

Testgetriebene Webentwicklung mit PHPUnit Testgetriebene Webentwicklung mit PHPUnit Oliver Cremerius 17.01.2013 FH AACHEN UNIVERSITY OF APPLIED SCIENCES FACHBEREICH WIRTSCHAFTSWISSENSCHAFTEN WWW.FH-AACHEN.DE Testgetriebene Webentwicklung mit PHPUnit

Mehr

Programmierung 2 Studiengang MI / WI

Programmierung 2 Studiengang MI / WI Programmierung 2 Studiengang MI / WI Dipl.-Inf., Dipl.-Ing. (FH) Michael Wilhelm Hochschule Harz FB Automatisierung und Informatik mwilhelm@hs-harz.de Raum 2.202 Tel. 03943 / 659 338 FB Automatisierung

Mehr

Testen von Softwaresystemen. 13. Januar 2015

Testen von Softwaresystemen. 13. Januar 2015 Testen von Softwaresystemen 13. Januar 2015 Überblick Was umfasst das Testen von Software? Warum sollte man Software testen? Motivation für Software-Tests Wie sollte man Software testen? Grundlegende Teststrategien

Mehr

Info: Standard DO-178B. 5. Mocking. Zusammenspiel von Klassen testen. Allgemein: Klassen testbar machen

Info: Standard DO-178B. 5. Mocking. Zusammenspiel von Klassen testen. Allgemein: Klassen testbar machen Info: Standard DO-178B Zertifizierung Federal AviationAdministration (FAA), Software für Luftverkehrssysteme durch Standard DO-178B für requirement-based Tests and Code Coverage Analyse DO-178B-Levels

Mehr

Web-Testen mit JUnit und HttpUnit. Kai Schmitz-Hofbauer Lehrstuhl für Software-Technik Ruhr-Universität Bochum

Web-Testen mit JUnit und HttpUnit. Kai Schmitz-Hofbauer Lehrstuhl für Software-Technik Ruhr-Universität Bochum 1 Web-Testen mit JUnit und HttpUnit Kai Schmitz-Hofbauer Lehrstuhl für Software-Technik Ruhr-Universität Bochum 2 Inhalt Entwicklertests in der Praxis Unit-Testing JUnit HttpUnit Praktisches Beispiel Bewertung

Mehr

SEP 114. Design by Contract

SEP 114. Design by Contract Design by Contract SEP 114 Design by Contract Teile das zu entwickelnde Programm in kleine Einheiten (Klassen, Methoden), die unabhängig voneinander entwickelt und überprüft werden können. Einheiten mit

Mehr

Prinzipien Objektorientierter Programmierung

Prinzipien Objektorientierter Programmierung Prinzipien Objektorientierter Programmierung Valerian Wintner Inhaltsverzeichnis 1 Vorwort 1 2 Kapselung 1 3 Polymorphie 2 3.1 Dynamische Polymorphie...................... 2 3.2 Statische Polymorphie........................

Mehr

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2 Inhaltsverzeichnis 1 Einführung 2 1.1 Warum Softwaretests?.................................... 2 2 Durchgeführte Tests 2 2.1 Test: allgemeine Funktionalität............................... 2 2.1.1 Beschreibung.....................................

Mehr

Allgemein: Klassen testbar machen. 5. Mocking. Mocks programmieren. Zusammenspiel von Klassen testen

Allgemein: Klassen testbar machen. 5. Mocking. Mocks programmieren. Zusammenspiel von Klassen testen 5. Mocking Allgemein: Klassen testbar machen Wie werden Klassen testbar Entwicklung von Mocks mit der Hand Einführung in JMock Spezifikation von Mocks mit JMock Wann ist Mocking-Werkzeug sinnvoll Literatur:

Mehr

Code verifizieren mittels

Code verifizieren mittels Code verifizieren mittels Unit- und Regressionstests Institut für Numerische Simulation, Universität Bonn Seminarreihe Technische Numerik Wozu sollen gut sein? Was für Testarten gibt es? Wie funktionieren

Mehr

Objektorientierte Programmierung

Objektorientierte Programmierung Objektorientierte Programmierung 1 Geschichte Dahl, Nygaard: Simula 67 (Algol 60 + Objektorientierung) Kay et al.: Smalltalk (erste rein-objektorientierte Sprache) Object Pascal, Objective C, C++ (wiederum

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung Kapitel 6 Vererbung Vererbung 1 Ziele Das Vererbungsprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen

Mehr

Verhindert, dass eine Methode überschrieben wird. public final int holekontostand() {...} public final class Girokonto extends Konto {...

Verhindert, dass eine Methode überschrieben wird. public final int holekontostand() {...} public final class Girokonto extends Konto {... PIWIN I Kap. 8 Objektorientierte Programmierung - Vererbung 31 Schlüsselwort: final Verhindert, dass eine Methode überschrieben wird public final int holekontostand() {... Erben von einer Klasse verbieten:

Mehr

Programmierprojekt. Anne0e Bieniusa Sommersemester 2014

Programmierprojekt. Anne0e Bieniusa Sommersemester 2014 Programmierprojekt Anne0e Bieniusa Sommersemester 2014 Phasen der So;ware- Entwicklung Planungsphase DefiniConsphase Entwurfsphase ImplemenCerungsphase Testphase Wasserfall- Modell Einführungs- und Wartungsphase

Mehr

Software Engineering Klassendiagramme Einführung

Software Engineering Klassendiagramme Einführung Software Engineering Klassendiagramme Einführung Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Aufgabe Erstellen Sie eine Klasse Person in Java. Jede Person verfügt

Mehr

Agiles Testen. Gedankensammlung. 17. November 2013 - Patrick Koglin

Agiles Testen. Gedankensammlung. 17. November 2013 - Patrick Koglin Agiles Testen Gedankensammlung 17. November 2013 - Patrick Koglin Inhalt Reflektion: Agilität notwendig? Wo? Eigenschaften agiler Entwicklung Quality is everyone s responsibility Qualität möglich machen

Mehr

Java: Vererbung. Teil 3: super() www.informatikzentrale.de

Java: Vererbung. Teil 3: super() www.informatikzentrale.de Java: Vererbung Teil 3: super() Konstruktor und Vererbung Kindklasse ruft SELBSTSTÄNDIG und IMMER zuerst den Konstruktor der Elternklasse auf! Konstruktor und Vererbung Kindklasse ruft SELBSTSTÄNDIG und

Mehr

Eine Klasse beschreibt Objekte mit gleichen Attributen und Methoden.

Eine Klasse beschreibt Objekte mit gleichen Attributen und Methoden. Grundwissen Informatik Objekt Attribut Methoden Als Objekte bezeichnet man alle Gegenstände, Dinge, Lebewesen, Begriffe oder Strukturen unserer Welt ( Autos, Räume, Bakterien, Lehrer, Schüler, Kunden,

Mehr

Qualitätsmanagement im Projekt

Qualitätsmanagement im Projekt Software-Engineering Qualitätsmanagement im Projekt Vorlesung im Wintersemester 2008/2009 Fakultät Wirtschaftsinformatik Klaus Mairon, M.Sc. Inhalte Messen und Bewerten: Metriken in der Qualitätssicherung

Mehr

Softwaretests in Visual Studio 2010 Ultimate Vergleich mit Java-Testwerkzeugen. Alexander Schunk Marcel Teuber Henry Trobisch

Softwaretests in Visual Studio 2010 Ultimate Vergleich mit Java-Testwerkzeugen. Alexander Schunk Marcel Teuber Henry Trobisch Softwaretests in Visual Studio 2010 Ultimate Vergleich mit Java-Testwerkzeugen Alexander Schunk Henry Trobisch Inhalt 1. Vergleich der Unit-Tests... 2 2. Vergleich der Codeabdeckungs-Tests... 2 3. Vergleich

Mehr

Systematisches Testen von Software

Systematisches Testen von Software Programmierung Systematisches Testen von Software Markus Eckstein Systematika Information Systems GmbH Kurfürsten-Anlage 36 69115 Heidelberg markus.eckstein@systematika.com Zusammenfassung Die wichtigsten

Mehr

Seminar Simulation und Bildanalyse mit Java SS2004. Themenschwerpunkt: Tests in Informatik und Statistik

Seminar Simulation und Bildanalyse mit Java SS2004. Themenschwerpunkt: Tests in Informatik und Statistik Einführung in den Softwaretest Seminar Simulation und Bildanalyse mit Java SS2004 Themenschwerpunkt: Tests in Informatik und Statistik Arbeit von Christian Aich und Robert Reeb Thema 2: Einführung in den

Mehr

Qualität von Software - Prof. Schlingloff, Lackner - SS2013 DYNAMISCHER TEST. Whitebox Testen mit JUnit

Qualität von Software - Prof. Schlingloff, Lackner - SS2013 DYNAMISCHER TEST. Whitebox Testen mit JUnit 1 DYNAMISCHER TEST Whitebox Testen mit JUnit Übersicht 2 1. Grundlagen des Unittests 1. Units 2. Unit Testing 2. Testverfahren 1. Blackbox 2. Whitebox 3. Unit Testing mit Eclipse 4. Besprechung der Übungsaufgabe

Mehr

Problemstellung. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 24: Reflection 1. IDE und automatische Tests.

Problemstellung. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 24: Reflection 1. IDE und automatische Tests. Universität Osnabrück 1 Problemstellung 3 - Objektorientierte Programmierung in Java Vorlesung 24: Reflection 1 SS 2006 Prof. Dr. Frank M. Thiesing, FH Osnabrück Um ein Objekt anzulegen, eine seiner Methoden

Mehr

Markus Wichmann. Testen von Java Code mit. JUnit

Markus Wichmann. Testen von Java Code mit. JUnit Markus Wichmann Testen von Java Code mit JUnit Demotivation... Am Anfang war der Zeitdruck... Hilfe, ich habe doch keine Zeit zum Testen! Ich schreibe einfach keine Tests, dadurch werde ich schneller fertig

Mehr

Qualitätssicherungskonzept

Qualitätssicherungskonzept Softwaretechnikpraktikum Gruppe: swp15.aae SS 2015 Betreuer: Prof. Gräbe Datum: 15.06.2015 Tutor: Klemens Schölhorn Qualitätssicherungskonzept Projektteam: Felix Albroscheit Dorian Dahms Paul Eisenhuth

Mehr

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI Universität Osnabrück Drei-Schichten-Architektur 3 - Objektorientierte Programmierung in Java Vorlesung 6: 3-Schichten-Architektur Fachkonzept - GUI SS 2005 Prof. Dr. F.M. Thiesing, FH Dortmund Ein großer

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12 Vertretung von Prof. Dr. Blume WS 2011/12 Inhalt Test, Abnahme und Einführung Wartung- und Pflegephase gp Vorlesung Zusammenfassung Produkte und Recht (Folien von Prof. Blume) 2 , Abnahme und Einführung

Mehr

Java Einführung Methoden in Klassen

Java Einführung Methoden in Klassen Java Einführung Methoden in Klassen Lehrziel der Einheit Methoden Signatur (=Deklaration) einer Methode Zugriff/Sichtbarkeit Rückgabewerte Parameter Aufruf von Methoden (Nachrichten) Information Hiding

Mehr

Die Softwareentwicklungsphasen!

Die Softwareentwicklungsphasen! Softwareentwicklung Die Softwareentwicklungsphasen! Die Bezeichnungen der Phasen sind keine speziellen Begriffe der Informatik, sondern den allgemeinen Prinzipien zur Produktion integrierter Systeme entliehen.

Mehr

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008 Konzeption und Implementierung einer automatisierten Testumgebung, 10. Dezember 2008 1 Gliederung Einleitung Softwaretests Beispiel Konzeption Zusammenfassung 2 Einleitung Komplexität von Softwaresystemen

Mehr

Es sollte die MS-DOS Eingabeaufforderung starten. Geben Sie nun den Befehl javac ein.

Es sollte die MS-DOS Eingabeaufforderung starten. Geben Sie nun den Befehl javac ein. Schritt 1: Installation des Javacompilers JDK. Der erste Start mit Eclipse Bevor Sie den Java-Compiler installieren sollten Sie sich vergewissern, ob er eventuell schon installiert ist. Gehen sie wie folgt

Mehr

Softwaretests. verschiedene Testformen Testen im V-Modell: Anwendungsszenarien. Tests. Tests. Tests. Anforderungs- definition. Abnahmetest.

Softwaretests. verschiedene Testformen Testen im V-Modell: Anwendungsszenarien. Tests. Tests. Tests. Anforderungs- definition. Abnahmetest. Softwaretests verschiedene Testformen Testen im V-Modell: Anforderungs- definition Anwendungsszenarien Abnahmetest Grobentwurf Tests Systemtest Feinentwurf Tests Integrationstest Implementierung Tests

Mehr

Fachgebiet Informationssysteme Prof. Dr.-Ing. N. Fuhr. Programmierung Prof. Dr.-Ing. Nobert Fuhr. Übungsblatt Nr. 6

Fachgebiet Informationssysteme Prof. Dr.-Ing. N. Fuhr. Programmierung Prof. Dr.-Ing. Nobert Fuhr. Übungsblatt Nr. 6 Gudrun Fischer Sascha Kriewel programmierung@is.informatik.uni-duisburg.de Anmeldung zur Klausur! Übungsblatt Nr. 6 Um an der Klausur teilzunehmen, müssen sich Studierende der angewandten Informatik in

Mehr

SOFTWARE ENGINEERING 3 TESTVORBEREITUNGEN UND UNIT-TEST

SOFTWARE ENGINEERING 3 TESTVORBEREITUNGEN UND UNIT-TEST SOFTWARE ENGINEERING 3 TESTVORBEREITUNGEN UND UNIT-TEST Gliederung 2 0. 1. 2. 3. Vorstellung Testvorbereitungen Planungsphase Definitionsphase Implementierungs-, Abnahme-und Einführungsphase Testphasen

Mehr

Übung zur Vorlesung Einführung in Software Engineering

Übung zur Vorlesung Einführung in Software Engineering Übung zur Vorlesung Einführung in Software Engineering Wintersemester 2012/13, Richard Bubel und Martin Hentschel Übungsblatt 5: Testen Abgabeformat: Reichen Sie Ihre Lösung per SVN als eine PDF-Datei

Mehr

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16 Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle

Mehr

Test-Driven Design: Ein einfaches Beispiel

Test-Driven Design: Ein einfaches Beispiel Test-Driven Design: Ein einfaches Beispiel Martin Wirsing in Zusammenarbeit mit Matthias Hölzl, Piotr Kosiuczenko, Dirk Pattinson 05/03 2 Ziele Veranschaulichung der Technik des Test-Driven Design am Beispiel

Mehr

Testen mit JUnit. Martin Wirsing. Ziele. Arten von Tests. Testen. Whitebox-Test. Unit-Test

Testen mit JUnit. Martin Wirsing. Ziele. Arten von Tests. Testen. Whitebox-Test. Unit-Test 2 Ziele Testen mit JUnit Lernen Unit Tests zu schreiben Lernen mit Unit-Testen mit JUnit durchzuführen Martin Wirsing in Zusammenarbeit mit Michael Barth, Philipp Meier und Gefei Zhang 12/04 3 4 Testen

Mehr

Testen mit JUnit. Martin Wirsing. Ziele. Arten von Tests. Testen. Lernen Unit Tests zu schreiben Lernen mit Unit-Testen mit JUnit durchzuführen

Testen mit JUnit. Martin Wirsing. Ziele. Arten von Tests. Testen. Lernen Unit Tests zu schreiben Lernen mit Unit-Testen mit JUnit durchzuführen 2 Ziele Testen mit JUnit Lernen Unit Tests zu schreiben Lernen mit Unit-Testen mit JUnit durchzuführen Martin Wirsing in Zusammenarbeit mit Michael Barth, Philipp Meier und Gefei Zhang 12/04 3 4 Testen

Mehr

JUnit a Cook s Tour. Framework in Java Automatisierter Ablauf von Testfällen Testläufe kombinieren. Unterlagen als PDF auf der Übungsseite!

JUnit a Cook s Tour. Framework in Java Automatisierter Ablauf von Testfällen Testläufe kombinieren. Unterlagen als PDF auf der Übungsseite! JUnit a Cook s Tour Ziel des Frameworks Framework in Java Automatisierter Ablauf von Testfällen Testläufe kombinieren Design des Frameworks Beginne bei Nichts Schritt für Schritt aus passenden Mustern

Mehr

Autor: Michael Spahn Version: 1.0 1/10 Vertraulichkeit: öffentlich Status: Final Metaways Infosystems GmbH

Autor: Michael Spahn Version: 1.0 1/10 Vertraulichkeit: öffentlich Status: Final Metaways Infosystems GmbH Java Einleitung - Handout Kurzbeschreibung: Eine kleine Einführung in die Programmierung mit Java. Dokument: Autor: Michael Spahn Version 1.0 Status: Final Datum: 23.10.2012 Vertraulichkeit: öffentlich

Mehr

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Jan Düttmann Archimedon Software + Consulting GmbH & Co. KG Marienstraße 66 32427 Minden Stephan Kleuker Hochschule

Mehr

Testen mit JUnit. Martin Wirsing. in Zusammenarbeit mit Matthias Hölzl, Nora Koch 05/03

Testen mit JUnit. Martin Wirsing. in Zusammenarbeit mit Matthias Hölzl, Nora Koch 05/03 Testen mit JUnit Martin Wirsing in Zusammenarbeit mit Matthias Hölzl, Nora Koch 05/03 2 Ziele Lernen Unit Tests zu schreiben Lernen mit Unit-Testen mit JUnit durchzuführen 3 Testen Da die meisten Programme

Mehr

Jetzt sollt ihr von der Vorlage der Grundversion 1.0 ein eigenes Textadventure erstellen.

Jetzt sollt ihr von der Vorlage der Grundversion 1.0 ein eigenes Textadventure erstellen. Teil B: Erweiterungen Jetzt sollt ihr von der Vorlage der Grundversion 1.0 ein eigenes Textadventure erstellen. Die folgenden Aufgaben und Ausführungen geben einige Hilfestellungen, welche (mindestens

Mehr

Projektmanagement. Vorlesung von Thomas Patzelt 9. Vorlesung

Projektmanagement. Vorlesung von Thomas Patzelt 9. Vorlesung Projektmanagement Vorlesung von Thomas Patzelt 9. Vorlesung 1 Pläne Kein Plan überlebt die erste Feindberührung - Feldmarschall Helmuth von Moltke Prognosen sind schwierig, besonders wenn sie die Zukunft

Mehr

PIWIN I. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I. Vorlesung 3 SWS WS 2007/2008

PIWIN I. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I. Vorlesung 3 SWS WS 2007/2008 PIWIN I Kap. 7 Objektorientierte Programmierung - Einführung 1 PIWIN I Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I Vorlesung 3 SWS WS 2007/2008 FB Informatik

Mehr

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Prof. Dr. Wilhelm Schäfer Paderborn, 15. Dezember 2014 Christian Brenner Tristan Wittgen Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Aufgabe 1 Codegenerierung

Mehr

6 Produktqualität Systeme: Integrationstest [sehr stark gekürzt]

6 Produktqualität Systeme: Integrationstest [sehr stark gekürzt] 1 Software-Qualitätssicherung 2 Integrationsstrategien big bang 6 Produktqualität Systeme: Integrationstest [sehr stark gekürzt] nicht-inkrementell geschäftsprozeßorientiert Prof. Dr. Helmut Balzert Lehrstuhl

Mehr

Testen. SEPR Referat: Testen - Oliver Herbst

Testen. SEPR Referat: Testen - Oliver Herbst Testen Inhalt 1. Grundlagen des Testens 2. Testen im Softwarelebenszyklus 3. Statischer Test 4. Dynamischer Test 5. Besondere Tests 2 1. Grundlagen des Testens 3 Grundlagen des Testens Motivation erfüllt

Mehr

3: Systematisches Testen

3: Systematisches Testen Stefan Lucks 3: Systematisches Testen 70 E für Sichere Vert. Systeme (2007) 3: Systematisches Testen Testen ist ein Prozess, ein Programm mit der Absicht auszuführen, Fehler zu finden. Man muss destruktiv

Mehr

Testen - Konzepte und Techniken

Testen - Konzepte und Techniken Testen - Konzepte und Techniken Magdalena Luniak 21.11.2007 Magdalena Luniak () Testen - Konzepte und Techniken 21.11.2007 1 / 42 Übersicht 1 Motivation 2 Grundbegrie 3 Testen im Softwareentwicklungsprozess

Mehr

Starthilfe für C# Inhaltsverzeichnis. Medien- und Kommunikationsinformatik (B.Sc.) Alexander Paharukov. Informatik 3 Praktikum

Starthilfe für C# Inhaltsverzeichnis. Medien- und Kommunikationsinformatik (B.Sc.) Alexander Paharukov. Informatik 3 Praktikum Starthilfe für C# Inhaltsverzeichnis Allgemeines... 2 Bezugsquellen... 2 SharpDevelop... 2.NET Runtime... 2.NET SDK... 2 Installation... 2 Reihenfolge... 2 Vorschlag für eine Ordnerstruktur... 3 Arbeit

Mehr

Praktische Übung 'JUnit-Test'

Praktische Übung 'JUnit-Test' Praktische Übung 'JUnit-Test' Starten Sie für die folgende Übung Eclipse und laden Sie das Testprojekt von folgender URL: http://pi.informatik.uni-siegen.de/berlik/swt/currency.zip Darin ist die Klasse

Mehr

Testen von grafischen Benutzeroberflächen

Testen von grafischen Benutzeroberflächen Seminarvortrag 10: Testen von grafischen Benutzeroberflächen 2004 / 06 / 28 Clemens Sommer, Gerald Peter Übersicht Motivation GUI Allgemein Fehlerquellen und deren Auswirkungen GUI Testwerkzeuge JUnit

Mehr

Klassenentwurf. Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? Objektorientierte Programmierung mit Java

Klassenentwurf. Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? Objektorientierte Programmierung mit Java Objektorientierte Programmierung mit Java Eine praxisnahe Einführung mit BlueJ Klassenentwurf Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? 1.0 Zentrale Konzepte

Mehr

6 Systematisches Testen von Programmen

6 Systematisches Testen von Programmen 6 Systematisches Testen von Programmen Testen Untersuchung des Source-Codes nach Fehlern und Anomalien Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 6 p.1/24 Untersuchung des Source-Codes

Mehr

Lösungen zum Test objektorientierter Software

Lösungen zum Test objektorientierter Software Lösungen zum Test objektorientierter Software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14. März 2013 HOM/FHTeL Lösungen zum Test objektorientierter Software

Mehr