Im letzten Artikel [1] haben wir uns mit automatischen Integrationstests mit ASP.NET Core beschäftigt. In diesem Artikel baue ich darauf auf und ergänze das Thema um eine sehr spannende Variante zum Mocking fremder Services. Die meisten Entwickler kennen das Problem. Sobald man auf der Integrations- oder Systemtestebene testen möchte, muss man sich über die Abhängigkeiten zu anderen Services Gedanken machen. Das fängt bereits bei der Datenbank an und hört dort leider nicht auf. Es geht i. d. R. auch um andere Services, die während des Testens benötigt werden. Zur Lösung des Problems gibt es grundsätzlich zwei Varianten: Man bindet externe Services während des Tests an oder man versteckt sie hinter einer Schnittstelle und baut einen Mock darum. Die erste Variante ist zwar realitätsnäher, hat aber einige gewichtige Nachteile. So ist die Laufzeit von Tests länger, man hängt vom Status eines externen Service ab und mehrere, konkurrierend laufende Tests können zum Problem werden. Mit Testcontainers können wir die meisten dieser Nachteile Streichen. Wie genau erkläre ich in diesem Artikel.
Softwaretest
Automatische Integrationstests mit ASP.NET Core
Softwaretest ist ein Thema, was jeden Softwareentwickler stets begleitet. Wenn es um Testautomatisierung geht, erhalten wir dazu ein breites Set an Werkzeugen in die Hand gedrückt. Das geht bei Testframeworks wie xUnit los und geht über die Integration solcher Frameworks in moderne IDEs wie Visual Studio und Rider weiter. In diesem Beitrag möchte ich mir eines dieser Werkzeuge herauspicken und ins Rampenlicht rücken: Es geht um Integrationstests mit ASP.NET Core. Warum? Genau diese Art von Tests hat einen sicheren Platz in meinem Werkzeugkoffer eingenommen. Es passt sehr gut zu der Art, wie ich Testautomatisierung und das Thema Testpyramide / Testdiamant schon seit sehr langer Zeit sehe (mehr dazu unter [1]). Ich setze bei Testautomatisierung i. d. R. mehr auf einen sog. “Testdiamanten”, als auf eine “Testpyramide”. Dafür gibt es viele Gründe. Ein wichtiger ist, dass damit das Verhalten einer Softwarekomponente auf einer höheren Ebene getestet und damit festgezogen wird. So viel möchte ich jetzt aber nicht über die Gründe schreiben, sondern jetzt zum Thema des Artikels kommen.
Um was geht es beim Testen?
Neulich stand am .Net Usergroup-Treffen in Regensburg das automatisierte Testen auf der Agenda [1]. Grundsätzlich ein wichtiges Thema, nicht nur für mich, sondern auch für viele andere Softwareentwickler – alleine die hohe Teilnehmerzahl macht dies deutlich. An dieser Stelle direkt ein Dank an den Sprecher Kenny Pflug, er hat das Thema gut dargestellt – auch wenn es die eine oder andere Kritik an dem Beispielprogramm gab ;). Bei dem Vortrag konnte ich einige Dinge dazulernen, beispielsweise nennt sich das, was ich normalerweise als “Testdriven Development” in der Arbeit vorantreibe, in Wirklichkeit “Behavior Driven Development”. Naja.. ich mache mir halt nicht viel aus Schlagworten 😉
MSTest, oder wie ich es verwende
UnitTests oder Ansätze der testgetriebenen Entwicklung werden aktuell häufig bei Usergroups oder Fachkonferenzen angesprochen. Erst diese Woche war ich auf einem Usergroup-Treffen in Nürnberg genau zu diesem Thema. Ich persönlich beschäftige mich damit schon etwas länger, habe testgetriebene Ansätze bereits mehrmals bei passenden Anwendungsfällen durchgeführt und war damit auch stets sehr zufrieden. Bei dem genannten Vortrag musste ich aber feststellen, dass sich das, was ich persönlich mit diesen Tests mache, mittlerweile schon teils deutlich von der Theorie unterscheidet. Hier in diesem Beitrag möchte ich entsprechend meine Sicht auf UnitTests und testgetriebene Ansätze im Allgemeinen beschreiben.Um ganz von vorne anzufangen: Ich verwende das in Visual Studio integrierte MSTest seit ca. 3-4 Jahren, vorher habe ich keinen einzigen automatisierten Test geschrieben. Ausgelöst wurde das ganze schlicht durch den Wunsch, gewisse Logiken nicht immer manuell neu testen zu müssen. Zudem habe ich an mir und auch bei Bekannten festgestellt, dass man sich gerne Testoberflächen bastelt, um damit neu entwickelte Logik-Bausteine zu testen. Diese Testoberflächen verschwinden aber gerne im Laufe der Entwicklung wieder oder werden aus Gründen der schlechten Usability einfach nicht mehr zum Nachtesten verwendet. UnitTests waren bzw. sind meiner Ansicht nach ein besserer Weg um genau das Gleiche zu erreichen. Vorteil: Die Testlogik bleibt im Projekt bestehen und kann jederzeit ausgeführt oder gar direkt in den Build-Prozess integriert werden.