|
|
asd |
|
|
\ No newline at end of file |
|
|
Zur Vorbereitung und Einarbeitung in Eclipse und JUnit sollen Sie dieses bestehende, erst teilweise fertig gestellte Programm (GTD) erweitern.
|
|
|
## Aufgabenbeschreibungen der Varianten
|
|
|
|
|
|
|
|
|
* [Aufgabenbeschreibung - Variante A (ContextlistController)](uploads/2e8e6faa1c6f783b06bb57ab5861a421/aufgabenbeschreibung_aufwaermprojekt_variante_a_mit_sequenzdiagramm.pdf)
|
|
|
|
|
|
* [Aufgabenbeschreibung - Variante B (JobController)](uploads/aaf30c4c7294db806b3c9f4b10afcd43/aufgabenbeschreibung_aufwärmprojekt_variante_b_mit_sequenzdiagramm.pdf)
|
|
|
## Projekt importieren
|
|
|
|
|
|
Zunächst müssen Sie das Projekt in die Entwicklungsumgebung Eclipse importieren. Gehen Sie dafür wie folgt vor:
|
|
|
|
|
|
|
|
|
1. Starten Sie Eclipse über *Anwendungen → Development → Eclipse*.
|
|
|
2. Klicken Sie unter *Fil*e auf *Import*.
|
|
|
3. Wählen Sie im folgenden Dialog unter *Git* den Punkt *Projects from Git* aus und klicken Sie auf *Next*.
|
|
|
4. Wählen Sie nun die Option *Clone URI* und klicken Sie auf *Next*.
|
|
|
5. Geben Sie als URI
|
|
|
|
|
|
[https://sopra-gitlab.cs.tu-dortmund.de/beispielprojekt/gtd.git](https://sopra-gitlab.cs.tu-dortmund.de/beispielprojekt/gtd.git)
|
|
|
|
|
|
sowie die GitLab-Login-Daten ein und klicken Sie auf *Next*.
|
|
|
6. **Variante A**: Wählen Sie *varianteA* aus und klicken Sie zweimal auf *Next*.
|
|
|
7. **Variante B**: Wählen Sie *varianteB* aus und klicken Sie zweimal auf *Next*.
|
|
|
8. Wählen Sie *Import existing Eclipse projects* aus und klicken Sie auf *Next*.
|
|
|
Klicken Sie auf *Finish*.
|
|
|
|
|
|
|
|
|
## Hinweise zu JUnit
|
|
|
|
|
|
In Eclipse finden Sie im linken Bildbereich den sogenannten **Package Explorer**, der eine Übersicht aller Projekte in einer Baumansicht anzeigt, darunter das **Beispielprojekt**.
|
|
|
In der Mitte der Eclipse-Oberfläche befindet sich der Bereich für den Editor. Wenn Sie bisher keine Datei mit Eclipse bearbeitet haben, ist dieser Bereich leer.
|
|
|
Sehen Sie sich zum Beispiel den Programmcode der Klasse *InboxController* an, zu finden unter *src → control* (Doppelklick auf *InboxController*).
|
|
|
|
|
|
Führen Sie nun folgende Schritte aus, um den Test des *InboxControllers* auszuführen:
|
|
|
|
|
|
1. Klappen Sie das GTD-Projekt im Package Explorer auf. Hier sehen sie die Quelltextverzeichnisse *src* und *tests* sowie weitere Einträge.
|
|
|
2. Klappen Sie das Quelltextverzeichnis *tests* auf. Hier befinden sich in den Unterverzeichnissen *control* und *model* alle Dateien, die Tests enthalten.
|
|
|
3. Klappen Sie das Paket *control* auf.
|
|
|
* Das Package enthält für jeweils eine Methode einer Controller-Klasse eine JUnit -Testklasse (Benennungs-Muster: <Controller-Name><MethodenName>Test)
|
|
|
4. Sehen Sie sich per Doppelklick *InboxControllerCreateNoteTest* an.
|
|
|
5. Den Test können Sie ausführen, indem Sie mit der rechten Maustaste auf der Testklasse klicken und unter *Run As* nun *JUnit Test* auswählen.
|
|
|
|
|
|
Statt des Package Explorers sehen Sie nun (auf der linken Seite) die **JUnit-Ansicht**. Sie können links mit den Reitern zwischen dem Package Explorer und der JUnit-Ansicht wechseln. Bleiben Sie zunächst in der JUnit-Ansicht. Der hellgrüne Balken signalisiert, dass alle Tests erfolgreich absolviert worden sind. Es ist eine gute Idee, nach jeder Änderung des Quellcodes die Tests auszuführen, um zu überprüfen, ob sich Fehler eingeschlichen haben.
|
|
|
|
|
|
Für die ausgeteilten Aufgaben gibt es eigene Tests, und zwar für …
|
|
|
|
|
|
* Variante A:
|
|
|
* ContextlistControllerExistContextlistTitleTest
|
|
|
* ContextlistControllerCreateContextlistTest
|
|
|
* ContextlistControllerRemoveFinishedJobsContextlistsTest
|
|
|
|
|
|
* Variante B:
|
|
|
* JobControllerExistJobTitleTest
|
|
|
* JobControllerSearchContextlistTest
|
|
|
* JobControllerRemoveJobFromProjectTest
|
|
|
|
|
|
Jede dieser Test-Klassen testet jeweils nur eine Funktion des jeweiligen Controllers. Im Package *controltestsuites* finden Sie TestSuites (**TestSuiteVariante(A/B)**), mit denen alle Tests zu einer Variante zusammen gestartet werden können
|
|
|
|
|
|
|
|
|
## Eigene Aufgabe bearbeiten
|
|
|
|
|
|
Wechseln Sie wieder in den Package Explorer und wählen nun einen entsprechenden Test zu Ihrer Aufgabe aus. Führen Sie diesen Test genauso aus, wie Sie es mit *InboxControllerCreateNoteTest* getan haben. Automatisch wechselt Eclipse in die JUnit-Ansicht. Der Balken wird nun dunkelrot sein, da Sie bisher noch nichts implementiert haben. Unterhalb des Tests sehen Sie detailliert, welche Tests fehlgeschlagen sind. Der erste Test, der fehlschlug, ist bereits ausgewählt (siehe **Pfeil A** in folgendem Bild zur **Variante A**):
|
|
|
|
|
|

|
|
|
Bild klicken um zu Vergrößern!
|
|
|
|
|
|
**Am wichtigsten ist hier die Fehlermeldung bei Pfeil B**. Mit Hilfe dieser Fehlermeldung können Sie am Besten herausbekommen, warum ein Test fehlschlug. Dies sollte deshalb ihr erster Anlaufpunkt sein. Durch einen Doppelklick auf einen Testfall, können Sie diesen einsehen.
|
|
|
|
|
|
Die Unittests sind wie das zu testende Programm in Java geschrieben und jeder Testfall korrespondiert hier mit einer Methode. Entsprechend öffnet sich der Editor und es wird die Zeile hervorgehoben, die den Fehlschlag verursachte. Die meisten Test-Klassen sind nach folgendem Muster aufgebaut:
|
|
|
|
|
|
|
|
|
* Eine Test-Klasse testet eine Methode im Projekt. Sie enthält Test-Methoden zu allen Testfällen, die nach dem Konzept der Äquivalenzklassentests gefunden wurden.
|
|
|
* Die *setUp()*-Methode wird vor jeder Test-Methode aufgerufen und erzeugt eine neue Testumgebung.
|
|
|
* Die Anordnung der Test-Methoden in der Test-Klasse spielt im Prinzip keine Rolle (**Wichtig: Die Reihenfolge bei der Ausführung ist beliebig!**), hier folgen wir aber aus Übersichtsgründen einer gewissen Ordnung:
|
|
|
* Überprüfung der Parameter
|
|
|
* Vorbedingungen für korrekten Ablauf nicht erfüllt (z.B. das Fehlen eines Objekts)
|
|
|
* korrekter Ablauf
|
|
|
* Was eine Test-Methode testet, ist am Methodennamen und JavaDoc ablesbar.
|
|
|
* In der Test-Methode wird die Testumgebung zunächst auf einen Test vorbereitet, z.B. indem eine Notiz in die Inbox eingefügt wird, bevor man diese mit der Entfernen-Methode des InboxControllers entfernt. Danach folgen der eigentliche Äquivalenzklassentest der zu testenden Methode.
|
|
|
|
|
|
Wenn Sie mit diesen Informationen nicht erkennen können, warum der Test versagt, bitten Sie Ihren Tutor um Hilfe. Dieser erklärt Ihnen auch, wie sie mit Eclipse debuggen können.
|
|
|
|
|
|
Um mit der Implementierung der Aufgabe zu beginnen, wechseln Sie wieder in den Package Explorer. Wählen Sie dann im Quelltextverzeichnis *src* das Paket *control* und die Controller-Klasse entsprechend ihrer Aufgabe aus. Im Editor können Sie nun die zu bearbeitenden Methoden ihrer Aufgabe finden, diese enthalten den Kommentar:
|
|
|
|
|
|
```// TODO Implementiere diese Methode, um die Spezifikationen von Ihrem Handout zu erfüllen.```
|
|
|
|
|
|
Innerhalb der Methode können Sie alles ändern, um ihre Aufgabe zu erfüllen.
|
|
|
|
|
|
## Tipps
|
|
|
|
|
|
* **Tipp 1**: Lesen Sie die Aufgabenstellung genau durch.
|
|
|
* **Tipp 2**: Gehen Sie inkrementell vor und versuchen Sie nicht, alle Fälle gleichzeitig abzudecken.
|
|
|
* **Tipp 3**: Führen Sie die Tests häufig aus, am schnellsten geht das über den grünen Play-Button in der Werkzeugleiste.
|
|
|
* **Tipp 4**: Die Klasse **ParamVal im package control** stellt Funktionen zur Validierung von Parametern bereit.
|
|
|
* **Tipp 5**: Nutzen Sie das Strukturmodell des Projekts. Dort finden Sie eine Übersicht über die Projektstruktur und die zur Verfügung stehenden Funktionen.
|
|
|
|