Training - Beratung - Projektarbeiten

www.David-Tielke.de

Test Driven Development mit .NET und C#–Tipp #2: Abhängigkeiten auflösen mit Stubs

Das Testen von Code ist eine wichtige und – für Entwickler – richtig coole Angelegenheit. Doch Testen ist weitaus mehr, als ein Testrunner und ein paar Attribute für Klassen und Methoden. In der Reihe “TDD Tipps” versuche ich regelmäßig Probleme zu erläutern, die beim Testen auftauchen und mit einem praktischen Hinweis einen Lösungsweg aufzuzeigen.

Unit-Tests sollen das Verhalten von nur einem einzigen Modul, für uns in diesem Fall einer Klasse, testen. Aber warum? Nehmen wir an wir testen die Methode Foo() in einer Klasse A die eine Referenz auf eine Klasse B hat. Im Laufe der Methode Foo() aus Klasse A wird die Methode Bar() aus Klasse B aufgerufen. Wenn wir jetzt A.Foo() testen, wird Code aus B.Bar() ausgeführt. Also ist das Ergebnis unseres Tests nicht mehr alleine von A, sondern auch von B abhängig und damit hängt auch der Testerfolg von A.Foo() von B.Bar() ab. Was hier noch nach einem einfachen Problem aussieht, wird spätestens zu einem Problem, wenn B eine externe Ressource nutzen würde, wie einen Webdienst, einen Mailserver, Datenbankserver o.ä. Aus dem und vielen anderen Gründen, sollte man in seinem Design immer so wenig Abhängigkeiten wie möglich haben. Was in der Theorie und in den zahlreichen Demos in Büchern und Konferenzen immer ganz einfach und simpel aussieht, gestaltet sich in der Praxis als teilweise sehr kompliziert. Wenn man ein Klassendesign entwirft, hat man an einigen Stellen zwangsläufig Abhängigkeiten.

Abbildung 1 verdeutlich das Problem noch einmal:

image

Abbildung 1: Klassendesign das getestet werden soll.

Würden wir nun einen Test für die Methode Foo() ) der Klasse A schreiben und dort ein Objekt der Klasse A instanziieren, würde dieses automatisch ein Objekt der Klasse B erzeugen, da A.Foo() ja deren Funktionalität nutzt.

Um solche Abhängigkeiten aufzulösen, bietet sich der Einsatz von Interfaces an. Mit nur einem Interface haben wir die Klassen voneinander entkoppelt und die Abhängigkeit zwischen A und B aufgelöst.image

Abbildung 2: Die Klassen A und B sind durch das Interface entkoppelt.

Zusätzlich übernimmt jetzt nicht mehr A selbst die Instanziierung von B, sondern wir injizieren dem Objekt von A mittels Konstruktorparameter b ein Objekt, das die Schnittstelle IB implementiert. Dadurch können wir von außen bestimmen, welches Objekt die Funktionalität IB.Bar() übernimmt, die wir von A.Foo() aus aufrufen.

Man stelle sich vor ,dass B.Bar() eine Datenbank aufruft. Gibt es dort einen Fehler, löst diese Methode eine InvalidOperationException aus. Unsere Methode A.Foo(), die ja B.Bar() aufruft, soll auf diese Exception mit einer CustomException reagieren. Wenn wir das mit dem Design aus Abbildung 1 testen möchten, müssten wir eine Datenbank aufsetzen, diese Tabellen in der Datenbank so manipulieren, dass in der Methode B.Bar() die gewünschte Exception auftritt und dann den Test für A.Foo() durchführen. Wir müssen quasi ein Szenario für B.Bar() simulieren, obwohl wir nur A.Foo() testen wollen. Das ist hier bereits verwirrend und in größeren Systemen führt das zu unglaublich kompliziertem Testcode den nach ein paar Tagen der Tester selbst nicht mehr versteht.

Mit dem Design aus Abbildung 2 ist das überhaupt kein Problem: In unserem Testprojekt legen wir einen sogenannten Stub an. Stub heißt, das er ein “dummer” Stellvertreter einer Interfaceimplementierung ist, der fest definierte Werte zurückgibt.

public class IBExceptionStub : IB
{
    public void Bar()
    {
        throw new InvalidOperationException("...");
    }
}

Listing 1: Ein Stub für einen Test der von B.Bar() eine Exception erwartet.

Schreiben wir nun also einen Test, der prüfen möchte, ob A.Foo() die erwartete CustomException auch tatsächlich auslöst, brauchen wir nur noch folgenden Code zu schreiben:

[TestMethod]
[ExpectedException(typeof(CustomException))]
public void Foo_DatabaseNotAvailable_CustomException()
{
    IB ib = new IBExceptionStub();
    A a = new A(ib);

    a.Foo();
}

Listing 2: Der Test für A.Foo() nutzt den ExceptionStub um einen Fehlerfall von B.Bar() zu simulieren.

Damit haben wir zwei Punkte erreicht:

Erstens können wir unterschiedlichste Verhalten von A in Abhängigkeit von Verhalten in B testen. Möchten wir z.B. ein Verhalten von A.Foo testen, wenn von B.Bar() aus der Datenbank ein ungültiger User geladen wird, schreiben wir einfach einen kleinen Stub.

Zweitens das Design ist wesentlich flexibler geworden durch die Entkopplung durch das Interface. Das Design aus Abbildung 1 wäre nicht durch eine Klasse C ersetzbar, welche die Methode Bar() ebenfalls anbietet. Das zweite Design könnte dies ohne Probleme, wenn C das Interface IB implementieren würde.

Das Ganze funktioniert so natürlich nur wenn Constructorinjection möglich ist. Sollte das nicht möglich sein, nutzt man dazu das ServiceLocator-Pattern. Aber das schauen wir uns in einem anderen Tipp genauer an.

Alle Beiträge der Reihe “TDD Tipps” sind hier zu finden.

Windows 8 Developer ​Day: Apps entwickeln​ mit HTML5 und JavaS​cript

Am 05.09.2012 hielt ich im Rahmen der Windows8 Developer Days von Microsoft einen App Development Workshop mit HTML5 und Javascript in Würzburg. Die knapp 40 Teilnehmer lernten in 8 Stunden alles wissenswerte zum Thema App-Entwicklung für Windows 8 mit Webtechnologien:

image

Neben den 5 Sessions zu Windows 8 blieb den anwesenden Entwicklern in den drei Pausen besonders viel Zeit zum Austausch und Netzwerken.

Wie abgesprochen, gibt es hier das RSS Reader Projekt zum Download. Ich hoffe es hat allen Anderen genau so viel Spaß gemacht, wie mir!

Links

ConfigurationSectionDesigner jetzt auch für Visual Studio 2010

Ein weiteres Mal musste ich dieses Jahr feststellen, warum viele Leute in der Softwareentwicklung ungern auf OpenSource-Software setzen. Hat man z.B. ein OpenSource-Addin für Visual Studio in einem Projekt verwendet und bestimmte Elemente hängen von diesem Tool ab, kann imageman erst dann auf eine neuere Entwicklungsumgebung migrieren, wenn auch das entsprechende Tool für diese angeboten wird. So geschehen bei einem meiner Projekte und dem Configuration Section Designer. Jeder der schon einmal komplexere Configuration Sections implementieren musste, weiß um diese mühselige Aufgabe und so konnte ich mit dem CSD diese Arbeit in Minuten anstatt Stunden durchführen. Leider blieb mir bisher die Migration dieses Projektes auf VS 2010 verwehrt, da CSD nur für VS 2008 erhältlich war und die ehemaligen Entwickler das Projekt nicht mehr weiterführen konnten.

Seit kurzem haben neue Entwickler das CSD-Projekt übernommen und nun gibt es das Addin für Visual Studio 2010 in der Alpha-Phase, allerdings konnte ich bisher weder Bugs noch Einschränkungen feststellen.

Das Tool erlaubt die grafische Entwicklung von Configuration Sections und ist in der VS 2010-Variante nochmal um zahlreiche Features erweitert worden. Jeder der öfters an Konfigurationsdateien arbeitet, sollte sich das Tool einmal genauer anschauen!

Links
Configuration Section Designer auf Codeplex