Mocks in der Testumgebung (Teil 2)

Im ersten Teil wurden Grundlagen zum Mock und das Beispielprojekt vorgestellt. Im zweiten Teil bauen wir einen Mock auf, der unsere Rest-Service-Anwendung interaktiv testet.

Nun kommt es zu der Frage: „Warum sollte ich bei diesem Beispiel einen Mock verwenden?“ Es ist immerhin eine einfache, übersichtliche Anwendung. Wir müssen allerdings beachten, dass wir die Standardfunktionalität der API testen wollen. Wenn wir einen GET- oder POST-Befehl durchführen, wird innerhalb des Rest-Services der komplette Weg zur Datenbank genommen, um auf die Daten, die bereits gespeichert sind, zuzugreifen. An diesem Punkt kommt der Mock ins Spiel. Es wird der Zugriff auf die Datenbank, mit Hilfe des Mocks simuliert. Somit kann sichergestellt werden, dass falls ein Fehler gefunden wird, dieser nichts mit dem Zugriff auf die Datenbank zu tun hat, sondern mit dem Bereich in dem wir den Test durchgeführt haben. Das wäre ein Beispiel für das Anwendungsgebiet. Ein weiteres wäre der Zugriff von außen auf die API. Im Normalfall würde eine solche API ein Frontend zur Eingabe der Informationen besitzen. Da wir allerdings die Pfade kennen, in die die Daten eingespeist werden, können wir ein API-Tool verwenden, welches das Frontend simuliert und spezifische Daten an die API schickt.

Ich werde in diesem Teil auf das Mock-Framework „Moq“ eingehen und das API-Test-Tool „Postman“.

Moq ist ein kleines und einfaches Mock-Framework für .Net oder C#. Es gibt mehrere Framework (NSubstitute, Rhino Mocks, etc …) doch diese sind meist recht kompliziert zu verwenden. Moq sticht in dem Sinne heraus, dass es eine einfache Syntax verwendet und für die meisten Anwendungsgebiete vollkommend ausreichend ist. Das Moq Framework-Package kann über Visual Studio einfach mit dem Nuget-Tool heruntergeladen und direkt in dem Quellcode eingebunden werden.

using System.Net.Http;
using Moq;
using NUnit.Framework;

Hier der einfache Aufbau eines Unit-Tests. Wir erstellen eine neue Heldenliste, welche ihre Daten aus der Datenbank bekommt. Mit diesen Informationen können wir den Service erstellen, der von der API abgerufen wird. Wir rufen den vierten Helden auf, den wir eingespeichert haben. In diesem Fall wäre es „Maria“.

[Test]
  public void TestMethodwithoutMoq()
{
     //Arrange (Create)
   Heldenliste liste = new Heldenliste();
   var heldAPI = new HeldenService(liste);
   string shouldBe = "Maria";
   //Act (Test)
   var ergebnis = heldAPI.GetHeroName(4);
   //Assert (Verify)
   Assert.That(ergebnis,Is.EqualTo(shouldBe),"Is Not as Aspected");
   }
[Route("api/Helden/{number}")]
[HttpGet]
public string GetHeroName(int number)
{
   Held hero = heldenAPI.GetHero(number)
   Return hero.name;
}

Jetzt nehmen wir den bereits vorhandenen Aufbau und ersetzen die Heldenliste mit einem Mock. Somit verwenden wir nicht mehr die Daten, die in der Datenbank gespeichert sind und haben die Anwendung erstmal von der Datenbank getrennt. Mit diesem Aufbau ist garantiert, dass keine Fehler von der Datenbankverbindung den Test behindern.

[Test]
public void TestMethodwithMoq()
{
    Helden mockHero = new Helden()
{
    Name = "Detlef",
    Klasse = "Zauberer",
    Alter = 40,
    Level = 14
};
//Arrange (Create)
var moqHeldenliste = new Mock();
moqHeldenliste.Setup(x => x.GetHero(It.IsAny()))
    .Returns(() => mockHero);

var heldenapi_mock = new HeldenAPI(moqHeldenliste.Object);
var shouldBe = "Detlef";
//Act (Test)
var ergebnis = heldenapi_mock.GetHeroName(It.IsAny());
//Assert (Verify)
Assert.That(ergebnis, Is.EqualTo(shouldBe), "Is Not as Aspectet");
}

Wenn das Moq-Framework integriert ist, kann man die Klasse-„Mock“ verwenden. Bei der Verwendung der Klasse gibt man an welche Klasse simuliert werden soll. Der nächste Schritt ist es dann den Mock mit der Setup()-Funktion zu konfigurieren. Wir geben an, dass egal nach welchem Helden gefragt wird(It.IsAny), immer der mockHero(Detlef) ausgegeben wird. Würden wir den Mock nicht konfigurieren, würde er bei dem Aufruf der GetHeroName()-Funktion einen Default-Wert als Integer nehmen. Bei diesem handelt es sich meist um „0“. Da allerdings keine Daten aus der Datenbank geholt werden, würde er einen Fehler zurückgeben.

Das Moq-Framework lässt sich gut nutzen, um die Funktionalitäten die die API innerhalb ihrer Anwendung aufruft zu testen. Bei dem direkten Aufruf der API kommt sie allerdings an ihre Grenzen. Hier kommt das API-Tool „Postman“ ins Spiel.

„Postman“ kann man als separate Anwendung installieren oder als Chrome-Plugin verwenden. Er ist ausgerüstet mit den meisten REST-Befehlen (GET, POST, PUT, etc…) und weist eine leicht bedienbare Oberfläche auf. Es ist möglich, Testfälle zu schreiben, die während der REST-Befehle ablaufen und mit den gesendeten oder empfangenen Daten arbeiten. Somit bauen wir mit ihm einen Mock, der das Frontend simuliert.

Es können „Collections“ erstellt werden, in denen man die REST-Befehle, die wir im letzten Teil verwendet haben, gespeichert werden können. Mit dem POST-Befehl haben wir die Heldin Maria über die API gespeichert. Jetzt wurde noch ein Testfall hinzugefügt, welcher den Antworttext überprüft, den wir von der API zurückbekommen haben. In einem positiven Fall wird zurückgemeldet, dass der gewünschte Held hinzugefügt wurde. In einem Negativ-Fall würden wir eine andere Meldung bekommen und der Testfall würde Failed zurückgeben.

Unserer „Collection“ fügen wir auch die Abfrage nach dem letzten zugefügten Helden hinzu. Es können noch viele weitere Abfragen mit eigenen Testfällen der „Collection“ hinzugefügt werden, doch für unser Beispiel reichen diese beiden. Nun ist es möglich die komplette „Collection“ zu starten. Der „Postman“ wird darauf hin nacheinander alle REST-Befehle aufrufen und ihre dazu gespeicherten Testfälle durchgehen. Somit bekommen wir am Ende solch ein Ergebnis:

Somit sehen wir, dass der Zugriff von außerhalb, auf die API funktioniert.
Mit diesen Beispielen sehen wir, dass mit dem Moq Framework die Anwendung hinter der API einfach getestet werden kann. Der „Postman“ hingegen vereinfacht, dass testen der API von Seiten des Internets.

Im nächsten Teil werden wir uns weiterhin mit diesem Thema befassen. Dabei werden wir in Docker eine kleine Testumgebung aufbauen, in dem der Rest-Service mit der Datenbank aufgebaut wird, und eine selbst geschriebene Mock Anwendung wird kontinuierlich Zugriff auf die Rest API versuchen. Diese Variante könnte man im späteren Verlauf auch als Lasttest verwenden.

Das was Mocks in der Testumgebung Teil 2 und hier geht es zu Teil 3.

Dieser Beitrag wurde verfasst von: