-
Notifications
You must be signed in to change notification settings - Fork 0
Testing
Version: 1.0 Author: Radomir
Tests haben die Einhaltung der in der Intefacedokumentation zugesagten Vor- und Nachbedingungen sowie Invarianten zu überwachen und sind somit dort für jede definierte Methode verpflichtend. Die Wichtigkeit der vollständigen Dokumentation der Interfaces ist somit klar, denn fehlt die vollständige Angabe der Vor- und Nachbedinungen(sowie der Invarianten) fehlt die Grundlage für den Test.(Siehe auch Codedokumentation) Obwohl Tests schreiben eine sehr intensive Angelegenheit ist, helfen diese den Code und Build insgesamt stabil zu halten, das Auftreten von RuntimeExceptions zu minimieren und sind auch eine Dokumentation der Codequalität. Testing ist folglich kein Nice-to-Have sondern wichtiger Bestandteil, auch wenn es wegen Termindruck- und Zeitmangel leider oft unter die Räder kommt. Guidelines zum Erstellen von Tests
- Für sämtliche Methodensignaturen, die in Interfaces definiert sind, sind auch verpflichtend Tests zu erstellen. Die Dokumentation der sämtlicher Methodensignaturen in Interfaces muss „vollständig nach aktuellen Wissensstand“ sein, da sonst kein sinnvoller sprich aussagekräftiger Test erstellt werden kann.
- Jeder Test benötigt auch eine klare Dokumentation, was er beabsichtigt zu testen und dies soll sich auch in seinem Namen widerspiegeln.
- Die Testklassen sollen sich in der gleichen Hierarchieebene wie ihre Interfacecounterparts befinden, aber anstatt im ‚main‘-Packet natürlich im ‚test‘-Packet, welches im Normalfall kein Deliverable an den Kunden darstellt. Die Namensgebung der Testklasse entspricht Interfacenamen + „Test“. z.B ./src.main.java.at.ac.tuwien.sepm.ws16.qse01.dao.ShootingDAO- ↔ ./src.test.java.at.ac.tuwien.sepm.ws16.qse01.dao.ShootingDAOTest. (Anmerkung: ein Präfix ‚Abstract‘ ist nicht notwendig, da man dies im IDE sowieso am vorangestellten Symbol erkennen kann und es den Namen ohne praktischen Nutzen verlängert.Also bitte weglassen!)
- Mockito (http://site.mockito.org/) ist das bevorzuge TestschreibFramework unserer Wahl. Wegen seiner Vorteile (Siehe unten) sollte es nicht schwer sein unser Team zu motvieren, die Tests im Mockito-way zu schreiben.
- JUnit ist das vorgeschriebene Framework, das Testschreiben notwendig ist, wie beim Einzelbespiel.
- Da unser Team sich für viele kurze Wochensprints statt drei langer Monatssprints entschieden hat, dürfen und sollen fertiggestellte Features solange, diese sich „fehlerfrei“ auf dem Entwicklungssystem builden lassen in den dev branch gemerged werden, wenn auch die Tests nicht vollständig sind. Wichtig ist es aber, dass nur Tests, die fehlerfrei durchlaufen in den „origin/dev“ Branch gemerged werden, um die Build-Fähigkeit auf dem devbranch immer zu bewahren und gewährleisten. Dennoch und das ist immanent wichtig, müssen alle noch zu schreibenden Tests mittels //TODO Dokumentation in ihre Testklasse vermerkt werden, damit man auf diesen nicht „komfortabler weise„ unter Zeitdruck vergißt. Man muss seinen Redstone-Issuetrack solange auf Status „Test“ halten, bis alle Tests vollständig und fehlerfrei implementiert sind. Wenn der Sprintzeit dazu zu kurz war, muss dies ehrlich in den nächsten Sprint übernommen werden und darf nicht unter den Teppich gekehrt werden.
- Erst nachdem alle Tests fertig gestellt sind und fehlerlos durchlaufen, kann die entsprechende Testklasse in den dev Branch gemergt und sobald das Resultat nachwievor build-fähig ist, gilt der Teststatus als beendet und die Reviewphase beginnt.
- Review ist kein Nice-to-Have sondern ein Muss und darf nie vom Codedeveloper/und Testschreiber durchgeführt werden, sondern muss vom entsprechenden Codebuddy durchgeführt werden. Der Codebuddy wird immer beim Scrum-meeting festgelegt oder bestätigt. Mehr zum Review siehe Teststrategie
- Testregression: Manchmal muss man Entities, Konstuktoren, Methodensignaturen leider ändern oder erweitern. Dies führt naturgemäß zu Tests, die nicht mehr fehlerfrei durchlaufen und entsprechend adaptiert werden müssen. Dazu gibt es nur zwei statthafte Vorgangsweisen. Entweder man adaptiert den Test sofort, damit der vollständig und fehlerfrei funktioniert oder später. Wenn man dies später vorhat, muss man den Test auskommentieren und unbedingt mit einem //TODO versehen, bevor man diese Klasse auf den dev Branch uploaded.
- Erst nachdem sämtliche Reviewmängel behoben sind, darf das Issue geclosed werden. Siehe Teststrategie
Libraries, welche für das Projekt verwendet werden, aber nicht vom Projektteam selbst stammen, sind von uns als ausreichend vertrauenswürdig und vorbildlich getestet eingestuft, da wir voraussetzen, daß andere Entwickler ihr Handwerk so gewissenhaft betrieben wie wir selbst.
Beim Test-driven development (TDD) schreibt man gar den Test für die Methodensignatur, bevor man die Methode selbst implementiert. Wir sind übereingekommen, dass dies für uns nicht die verpflichtende, sondern eine vom Testbeauftragten eventuell empfohlene Vorgangsweise ist. Man kann sich also aussuchen, welche Vorgangsweise einem besser liegt. Wichtig ist, das die Testphase für ein Feature solange anhält, bis die Tests vollständig sind und fehlerfrei durchlaufen. Bei Erweiterungen von Methodensignaturen und generell bei Umbauten fängt der Prozess Plan-Development-Test-Review von vorne an. Nach dem Beenden der Testphase beginnt die Reviewphase, die niemals durch dieselbe Person erfolgen darf, sondern durch den Codebody. Dieser muss den Code sowie die Tests verstehen und nachvollziehen können und muss den Implementierter auf logische Denkfehler, fehlende oder ungenügende Dokumentation, fehlende und ungenügende Tests sowie auf eventuell nicht eingehaltene Richtlinien aufmerksam machen und in einem Dokument festhalten, welches er zum Isssue attached. Der Implementierer merzt die Mängel aus und darf den Issue erst danach closen
Weil es sehr viele smackhafte Rezepte (http://www.chefkoch.de/rs/s0/mochito/Rezepte.html) gibt, aber das ist eine andere Geschichte.
- Es eliminiert sämtlichen zumeist unerwünschten Seiteneffekte, die beim Testschreiben ohne Mochito auftreten können, wie geworfene Exceptions, die das Builden des Mainprogramms behindern. Es hinterläßt keine
- Seine Anwendung ist sehr einfach zu erlernen und es ist unkompliziert.