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.

Es ist wieder Freitag und das heißt: #FrontendFriday! :)

Heute geht es um das Framework Bootstrap, welches der ein oder andere kennt, angewendet oder auch nur mal gehört hat.

Was ist Bootstrap?

Jeder möchte sich sein Leben einfach machen, deshalb gibt es auch Boostrap, welches ein Frontend-Framework ist. Es werden viele HTML- und CSS-Vorlagen bereitgestellt, um verschiedene Webseite-Elemente unterschiedlich darzustellen.

Hierzu gehören Formulare, Buttons, Tabellen, Navigationsleisten sowie ein Grid-System für Layouts. Über HTML- und CSS-Vorlagen hinaus ist es durch JavaScript-Module möglich, Interaktionen, wie z.B. Bilder-Slideshow, Tabs und Dialogboxen auf der Webseite einzubinden.

Bootstrap bietet alle Voraussetzungen, um responsive Design optimal zu gestalten, sei es für Desktop, Smartphone oder Tablet.

Ihr wollt wissen was Bootstrap an Layout und viele andere Features mit sich bringt, dann könnt ihr euch gerne die Dokumentation anschauen: https://getbootstrap.com/docs/4.3/getting-started/introduction/

Was ist jQuery?

Boostrap erleichtert die Arbeit eines Entwicklers in Sachen HTML und CSS. jQuery hingegen die JavaScript-Arbeit – es ist eine JavaScript-Bibliothek.

Es überbrückt technische Unterschiede verschiedene Browsern – ermöglicht komfortablen und kompakten Code, der im Vergleich zu reinem JavaScript häufig sehr viel kürzer ist.

Mehr zu jQuery: https://jquery.com/

Bootstrap verwendete für die JavaScript Modulen jQuery, jedoch nur bis Version 4.3

Warum verwendet Bootstrap 4.3 kein jQuery mehr?

Etwas was die Community wohl bereits länger diskutiert hat, war der Abschied von jQuery für die DOM-Manipulation (Document Object Model) bzw. -Navigation.

Bootstrap wird ohne jQuery auskommen und dies wird derzeit entfernt. Bootstrap ist nicht das erste Tool, das diesen Schritt geht, auch Ember und GitHub arbeiten bereits nicht mehr standardmäßig mit jQuery.

Der wichtigste Punkt hierbei ist: Schonen von Ressourcen auf dem Server!

Bye Bye jQuery – Hello Hugo.js

Bei Hugo handelt es sich um einen Static Site Generator, der in Go geschrieben ist. Hugo beschreibt sich selbst: world’s fastest static website engine.

Hugo zählt zu den Statischen Webseiten-Generatoren und kann ganz ohne weitere Hilfsmittel genutzt werden.

Aber warum nun Hugo.js?

Es handelt sich hierbei um einen statischem Webseitengenerator – Dies bedeutet, dass der Inhalt nicht jedes Mal neu generiert wird, sondern nur, wenn sich der Inhalt der jeweiligen Seite ändert.

Insbesondere ermöglicht es Hugo, dass nur diejenigen HTML-Dokumente der jeweiligen Webseite neu gebaut werden müssen, in denen Änderungen auftraten.

Hierdurch sollen die Ressourcen des Servers geschont und eine hohe Effizienz von diesem erreicht werden.

Mehr zu Hugo: https://gohugo.io/getting-started/

Fazit

jQuery hat viel Arbeit für den Frontend-Entwickler entnommen, vor allem, wenn man Einsteiger ist. Im Gegensatz zum reinem JavaScript war auch der Code häufig viel kürzer und lesbarer.

Um Ressourcen sowohl auf dem Server, als auch lokal beim Entwickeln zu sparen, sodass die Inhalte nicht immer wieder neu erstellt werden müssen, ist Hugo hierbei sehr Ressourcen- und Zeit-Sparender.