Hallo Spa\u00df-Coder.<\/p>\n
Wer von euch liefert gerne gro\u00dfartige Qualit\u00e4t ab? Wo beginnt gro\u00dfartige Qualit\u00e4t des gesamten Systems? Was ist Voraussetzung daf\u00fcr, dass eine Anwendung – bestehend aus vielen kleinen Bausteinen – unseren eigenen sowie den Anspruch unserer Kunden an eine hohe Qualit\u00e4t erf\u00fcllt? Wie w\u00e4re es, wenn wir das gesamte System testen? Wie w\u00e4re es, wenn jede einzelne Komponente des Systems getestet ist? Wenn jeder Baustein f\u00fcr sich funktioniert, funktioniert dann auch das gesamte System?<\/p>\n
<\/p>\n
Die kleinste Einheit in einem System, nennen wir sie Methode, hat eine definierte Schnittstelle mit Ein- und Ausgaben und nach Anwendung der SOLID-Prinzipien eine beherrschbare Komplexit\u00e4t. Daher ist es vielleicht eine gute Idee, hier mit den Tests zu beginnen.<\/p>\n
Der Test von Komponenten hat zum Ziel, einen isolierten Baustein (z.B. eine Methode) losgel\u00f6st vom Rest der Anwendung zu testen und die Korrektheit abzusichern. Dieser isolierte Baustein wird auch als SUT – „system under test“ oder „subject under test“ bezeichnet [2]. Erstellen wir eine neue Klasse mit einzelnen Methoden, ist es leicht die Methoden isoliert zu betrachten. Schwieriger wird es, wenn nachtr\u00e4glich Komponententests f\u00fcr ein bestehendes System hinzugef\u00fcgt werden. Dabei besteht die Herausforderung, zu testende Einheiten vom Rest des System zu isolieren und somit f\u00fcr sich zu pr\u00fcfen. Welche Methoden und Techniken hierf\u00fcr bereitstehen, werden wir uns in einem sp\u00e4teren Artikel ansehen (siehe auch [1]).<\/p>\n
Sobald die Isolation nicht gegeben ist und zwei oder mehr von einander abh\u00e4ngige Komponenten zusammen getestet werden, sprechen wir von Integrationstests<\/em>, zu denen ein eigener Artikel erscheinen wird. Das bedeutet auch, dass jede Abh\u00e4ngigkeit zur Umwelt des SUT f\u00fcr den Komponententest zu entfernen ist. Also Zugriffe auf das Dateisystem, Netzwerke oder Datenbanken. Diese Abh\u00e4ngigkeiten sind f\u00fcr den Unit Test aufzul\u00f6sen, da wir keine direkte Kontrolle \u00fcber ein Netzwerk haben und wir auch gar nicht das Netzwerk, sondern unsere Komponente testen wollen. Doch wie kann ich eine Abh\u00e4ngigkeit zu einem Dateisystem tempor\u00e4r f\u00fcr die Ausf\u00fchrung der Tests aufl\u00f6sen?<\/p>\n Daf\u00fcr gibt es ein paar n\u00fctzliche Techniken, von denen nachfolgend einige vorgestellt werden.<\/p>\n Fake<\/strong><\/p>\n Ein Fake ist ein Objekt, welches sich in Teilen so verh\u00e4lt wie die Abh\u00e4ngigkeit zu unserem SUT, jedoch nur die Implementierungen enth\u00e4lt, welche wir f\u00fcr einen bestimmte Test ben\u00f6tigen. Dies kann sinnvoll sein, wenn die Abh\u00e4ngigkeit weitere Abh\u00e4ngigkeiten hat, schwer zu erstellen oder langsam ist.<\/p>\n Stub<\/strong><\/p>\n Ein Stub ist ein Objekt, welches die Abh\u00e4ngigkeit ersetzt und unserem SUT genau die f\u00fcr einen bestimmten Test festgelegten Daten zur\u00fcck gibt, unabh\u00e4ngig von den Eingabeparametern. Dies ist eine sehr einfache Methode, Abh\u00e4ngigkeiten f\u00fcr einen Test loszuwerden.<\/p>\n Mock<\/strong><\/p>\n Ein Mock ist ein Objekt, welches die Abh\u00e4ngigkeit ersetzt und unserem SUT je nach Eingangsparameter die von uns festgelegten Daten zur\u00fcck gibt. Mocks werden h\u00e4ufig mit Hilfe von entsprechenden Frameworks verwendet, die es deutlich vereinfachen, Mock-Objekte zu parametrieren und zu erzeugen.<\/p>\n Die Definition von Stub und Mock unterscheiden sich je nach Quelle. Die oben genannten Definition entstammt der Wikipedia [3] und entspricht der \u00fcblichen Verwendung von Mock-Frameworks [siehe auch [4]). Roy Osherove schreibt in [2], dass das Mock-Objekt selbst nach Aufruf des SUT gepr\u00fcft wird, da dies alle Aufrufe aufzeichnet und somit den Test validiert. Wir verwenden in den meisten F\u00e4llen die erste Definition, wenn wir mit Mock-Objekten arbeiten.<\/p>\n Wie bereits angesprochen, k\u00f6nnen diese Techniken deutlich leichter eingesetzt werden, wenn die Kopplung unseres SUT zu seinen Abh\u00e4ngigkeiten gering ist und SOLID angewendet wurde. So kann beispielsweise eine Fabrikklasse ein spezielles Objekt f\u00fcr den Test bereitstellen, wenn das DIP<\/a> angewendet wurde.<\/p>\n Der grunds\u00e4tzliche Aufbau eines Unit Tests ist immer gleich:<\/p>\n <\/p>\n Eine besondere Praktik\u00a0 im Zusammenhang mit Komponententests ist das Test-Driven-Development (TTD), bei dem der Test-First-Ansatz verfolgt wird. Dabei wird zuerst der Komponententest erstellt und anschlie\u00dfend der Produktionscode implementiert. Diese Vorgehensweise ist nicht zwingend erforderlich f\u00fcr das Schreiben von Komponententests, hat jedoch einige Vorteile, die wir in einem weiteren Artikel noch beleuchten werden.<\/p>\n <\/p>\n Die nachfolgenden Kriterien werden von guten Unit Tests erf\u00fcllt:<\/p>\n\n