Es war eine sehr warme Woche, aber dies haben wir auch überstanden und was fällt euch zu Freitag ein – Ganz genau It’s #FrontendFriday ;)

Im heutigem Post geht es um die Testpfade, welches sowohl im Frontend, Java Projekten, etc. eingesetzt bzw. getestet wird.

Was sind Testpfade?

Im Umfeld eines Projektes werden auch unter anderem andere Services angebunden, da von diesen bestimmte Informationen erhalten werden soll. Ihr möchtet über z.B. einem JUnit-Test testen, ob auch deine Implementierung das tut, was es auch machen sollte. Dies gibt es auch im Frontend.

Hierbei testet man ein Codeausführungsszenario, von dem ein bestimmtes Verhalten erwartet und geprüft wird.

Welche Testpfade gibt es?

Happy Path

Natürlich möchte man als erstes immer den Erfolgsfall bzw. Good-Case-Fall testen – Happy Path. Dies ist das einfachste Szenario, ohne dass Ausnahmen oder Fehlerzustände eintreten. Dieser Test stellt die Basisfunktionalität des Codeabschnitts dar – Happy Path ist das Mindeste, welches getestet werden sollte.

Natürlich möchte man sehr gerne vom Good-Case ausgehen, aber dieser reicht allerdings nicht aus, um die Funktionalität des Codes mit Verzweigung zu testen.

Scary Path

So schlimm sich dies auch anhört, sollten auch die Szenarien getestet werden, welches den Code zu einem Fehlverhalten oder ein einem Fehlzustand bringt. Der Scary Path ist vor allem dann zu testen, wenn durch das Fehlverhalten bzw. den Fehlerzustand ein hohes Risiko für die Stakeholder besteht.

Angry Path

Was ist wenn der angebundene Service einen Fehler zurückgibt? Ist dann euer Code noch stabil? Oder werden nur noch Fehler geworfen?

Es ist ärgerlich, wenn der angebundene Service einen Fehler zurückgibt, aber dafür hast du dir schon Gedanken gemacht und es auch deinem Code beigebracht, was es wie machen soll, wenn ein Fehler erhalten wird. Angry Path testet den Code, welches es zu einem Ausnahmeverhalten führt, jedoch in einem gültigen und funktionierenden Zustand verbleibt.

Delinquent Path

Du stellst bspw. für dein Projekt auch eine Oberfläche bereit. Du möchtest nicht, dass jede Person, welches die URL hat, darauf kommt – also berechtigst du nur bestimmte Personen mit bestimmten Zugangsdaten. Mit dem Delinquent Path wird die Autorisierung, Authentifizierung, Berechtigung oder andere Sicherheitsmaßnahmen getestet.

Desolate Path

Diesen Test macht im Prinzip jeder Standardmäßig – Was ist wenn null, 0, 1, -1 oder auch NaN zurückgegeben wird? Was soll dann passieren? Hierzu ist der Desolate Path zuständig, welches diesen Fall testet.

Forgetful Path

Um Daten nicht zu verlieren oder auch um diese Weiterzuleiten, werden diese oft in einer Datenbank gespeichert – Aber was ist, wenn die Datenbank nicht vorhanden oder verfügbar ist? Dies soll der Forgetful Path testen.

Ihr habt Kundendaten, welches durch bestimmte Prozesse durchlaufen soll. Ihr speichert initial die Daten die ihr erhalten habt in der Datenbank. Zu diesem Zeitpunkt ist die Datenbank nicht verfügbar – Was soll geschehen? Soll eine Fehlermeldung geworfen werden? Genau hierzu ist der Forgetful Path-Test gut

Greedy Path

Auf der Oberfläche, hat der Anwender die Möglichkeit eine große Anzahl an Optionen zu wählen oder eine Vielzahl von Aktionen ausführen zu lassen – Greedy Path testet, dass die Aktionen innerhalb von kürzester Zeit ausgeführt werden.

Stressful Path

Was ist wenn der HTTP-Request zu lange dauert? Bricht es ab, oder wartet es solange, bis eine Antwort erhalten wird? Wie soll es sich verhalten, wenn es zu lange dauert? Wurde denn schon Gedanken über eine Timeout gemacht? Ja? Nein? Genau dies soll der Stressful Path-Test testen.