Wasserfallmodel Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Machbarkeitsstudie Auswählen des Produktes Voruntersuchung des Produkts Durchführbarkeitsuntersuchung Prüfen der ökonomischen Durchführbarkeit Ergebnis: „Stop or go“ Entscheidung Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Anforderungsdefinition Konzepterarbeitung mit Laien / Kunden Verständliche Szenarios Klärung der Funktionalität Nichtfunktionale Anforderungen Anforderungsdokumentation Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Analyse Grob-Entwurf in der „Problem-Domain“ Erfassen der Domain (Business-Model) Konzeption neuer (komplexer) Funktionalität Konzeption von (Architektur) Umbauten Architekturkonzepte Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Design Fein-Entwurf in der „Solution-Domain“ Arbeitsvorlage für den Entwickler Konzeption neuer (komplexer) Funktionalität Konzeption von (Architektur) Umbauten Architekturkonzepte Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Implementierung hier wird „gehackt“ Entwickler orientieren sich am Design-Dokument Tests Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Wartung Auslieferung Pflege vor Ort Bugfixing Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Probleme mit dem Wasserfall Alle Anforderungen zuerst ersten Phasen werden teuer Kunde bekommt nicht das, was er will Probleme werden spät entdeckt  Phasen werden Arbeitsschritte iterativer Durchlauf prototypisch usecase / scenario – driven Test-first Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Kostenschätzung Resultat aus Gruppendiskussion Pi mal Daumen Ergebnis: ca. ein Semester Modul und Phasen-basiert Schätzgrößen LOC, Seiten  Zeit Einzelschätzungen + Gesamtsumme Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Abgaben Abgaben per CVS setzen der Tags gemäß Aufgabenstellung v3 vor der Deadline in eclipse: Rechtsklick  Team  Tag as Version Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Organisatorische Hinweise Im OKA anmelden - bis Anfang Dezember, Veranstaltung „Softwaretechnik“ Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Testen - Motivation Testen ist Ausprobieren? GUI ‚durchklicken‘ System.out.println(…) Wer hat das kaputt gemacht? don't touch it if it works! Je nach „Qualität“ geht bis zu 50% der Arbeitszeit Debugging und Fehlersuche Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Unit Tests Testen eine ‚Einheit‘: Klasse Modul Komponente Werden programmiert Prüfen den Funktionsumfang Rufen nur die öffentliche Schnittstelle auf Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Vorteile von Unit Testing Tests sind: Reproduzierbar (von anderen) Automatisierbar und selbst auswertend Dokumentierend und Anwendungsbeispiel Tests decken Designfehler frühzeitig auf Der entstehende Code ist: Modular und einfach Änderungssicher Qualitativ hochwertiger => Weniger Fehler, Debugging und Fehlersuche Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Testen Ziel: Fehler finden IST-SOLL Vergleich z.B. mit JUnit Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Vorgehen beim Testen Test vor der Implementierung: Funktionalität abprüfen Alle möglichen Fehlerfälle prüfen aber keine Trivialitäten So wenig wie möglich implementieren Genau soviel, dass der Test erfolgreich ist Umfang vom Testcode: 15-50% Anteil am Gesamtcode Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Testgetriebene Entwicklung Funktionale Anforderung Test anlegen Schnittstelle anlegen Test implementieren Funktion implementieren Eine Iteration Zeit Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Tests für CoreWars Verwenden Junit 3.8 (siehe Beispiele) möglichst früh Tests schreiben, (Test-first) vor oder während der Implementierung Hinterher macht das keinen Spaß! Achtung: gemeinsame Deadline für Tests und Implementierung! Szenarien-basiert: Test „spielt“ ein Szenario durch Prüfen der Ergebnisse Vorgehen siehe Vorlesung Programmiermethodik Debugger (Breakpoints, Variables View...) nutzen! Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Tests für die 8 neuen Befehle Siehe existierende Tests in CUTest.java Selbes Schema: Instruktion(en) erzeugen Queue mit Program Counter befüllen Aktuelle Instruktion ausführen Sind die richtigen Änderungen im Core? Stimmt der neue Program Counter? Testet die Funktion der Opcodes Mindestens eine Test-Methode pro Opcode Und auch die Fehlerfälle Division durch 0 ... Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

JUnit Framework (1) Freies Open Source Framework http://www.junit.org/ Verwendet: 3.8.1, aktuell: 4.4 Autoren: Kent Beck & Erich Gamma Grundeinstellung: Das Feature funktioniert erst … … wenn ein Test geschrieben wurde Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

JUnit Framework (2) Tests in separaten Test-Klassen, aber im gleichen Paket Test-Methoden Instanzieren von Objekten Prüfung des Objektzustandes vor und nach Methodenaufrufen Assertion-Methoden Prüfung von Fehlerbehandlung (Exceptions) Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

JUnit Framework (3) Basisklassen für Test-Klassen: junit.framework.TestCase Stellt Assert-Methoden bereit TestRunner lassen Tests ablaufen: Eine Methode einer Test-Klasse Eine Test-Klasse komplett Mehrere Test-Klassen as TestSuite Grafisch oder Textmodus Oder direkt in Eclipse „Run As -> JUnit Test“ Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Aufbau einer Test-Klasse Tests werden thematisch in einer Klasse gesammelt: … extends TestCase … Jeder Test ist eine Methode: public void test<Name> throws Exception { … } Vor und nach jedem Test: public void setUp() { … } Objektstruktur aufbauen public void tearDown() { … } - aufräumen Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Assertion-Methoden Ausdrücke, die wahr sein müssen, sonst Abbruch der aktuellen Test-Methode assertEquals(soll, ist) Object, primitive Typen assertTrue(boolean) assert[Not]Null(Object), assert[Not]Same(obj1, obj2) Bei Fehlschlag oder fail(): Wirft junit.framework.AssertionFailedError Alle Methoden auch mit ‚String message‘ Parameter Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University

Testen - Vorgehen Erster Hinweis: Fehlermeldung! Stacktrace Debugging - Einkreisen eines Fehlers Breakpoints an „spannenden“ Stellen setzen Variablenbelegung / Objekstruktur überprüfen Methode schrittweise ausführen in interessante Methoden reinsteppen Tip: Fehler gefunden => reproduzierenden Test schreiben Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University