adesso BLOG

F.I.R.S.T. ist ein Akronym, welches verschiedene Prinzipien beim Schreiben von Unit-Tests umfasst. Die F.I.R.S.T.-Prinzipien wurden von Robert C. Martin in Clean Code kurz vorgestellt und in diesem Blog möchte ich weiter in die Tiefe dieser Prinzipien eingehen. Gerade beim Einstieg in die Programmierung können diese Prinzipien als Leitfaden dienen. Diese Prinzipien haben das Ziel, dass Unit-Tests verständlich, wartbar und aussagekräftig sind.

Ein Unit-Test soll genau das ausgewählte Stück Code testen. Doch oft ruft die zu testende Methode externe Services oder Datenbanken auf. Mocks können solche Abhängigkeiten durch Platzhalter ersetzen. Die drei in der Microsoft-Welt beliebten Mocking-Frameworks Moq, NSubstitute und FakeItEasy werden hier gegenübergestellt.

Um es mit der Herrin Galadriel aus Tolkiens “Der Herr der Ringe” zu sagen: “Die Welt ist im Wandel.” Zugegeben: das galt für die IT schon immer. Aber gerade die aktuellen Techniken und Trends stellen den Bereich Software Testing vor neue Herausforderungen. Um diesen Herausforderungen zu begegnen und das Wissen im Unternehmen aktuell und frisch zu halten, veranstaltet adesso jährlich den adesso testing day. In diesem Jahr im September fand er zum achten Mal statt.

Knowledge Sharing ist eines der Kernprobleme unserer Branche und zentraler Bestandteil vieler moderner Methodiken der Softwareentwicklung. Specifications by Example als Vorgehen kann hierbei unterstützen und bietet einen Rahmen, um eine gemeinsame Wissensbasis zu schaffen, Randfälle durch Tests im Vorfeld zu beschreiben und als Ergebnis eine lebende Spezifikation zu erstellen.

Stellt euch folgendes Szenario vor: Ein Unternehmen möchte seine Software intern testen, ohne dass auf externe Dienste zugegriffen wird. Dabei spielen die Kosten natürlich eine Rolle. In unserem Blog-Beitrag erklären wir daher, wie die Kosten für das Testen durch eine containerbasierte Testdurchführung reduziert werden können.

Eine gut wartbare Software minimiert den Aufwand für Fehlerbehebung, adaptive Wartung und folgende Change Requests deutlich. Aber was zeichnet gute Wartbarkeit aus und wie können wir diese erreichen? Nachdem wir uns im ersten Teil der Reihe “Wartbarkeit von Software” mit der Dokumentation beschäftigt haben, wollen wir nun in Teil 2 näher auf die Tests eingehen. Dazu beschäftigen wir uns mit den unterschiedlichen Testarten, mit Automatisierung und Testumgebungen und verdeutlichen die Notwendigkeit einer hohen Testabdeckung.

Das Testen von SAP S/4HANA ist nicht nur auf die Projektimplementierung und die GoLive-Phase eines Projekts beschränkt. Daneben sollten Standardfunktionalitäten und Erweiterungen des S/4HANA-Paketes mit berücksichtigt werden. Doch heißt dies auch immer mehr Aufwand? In meinem Blog-Beitrag erkläre ich, wie S/4HANA mit Digital Core nicht nur Geschäftsprozesse vereinfacht und beschleunigt, sondern auch das Testing.

Im Zuge der agilen Transformation im Projektkontext beim Kunden, ist die Verantwortung für die Erstellung und Durchführung von Lasttests, die zuvor an zentraler Stelle behandelt wurden, in die Teams gewandert. Jetzt sind die Teams plötzlich nicht nur für die Spezifikation der Tests, zum Beispiel durch die Beschreibung von „Klick-Pfaden“ in der Anwendung zuständig, sondern müssen sich auch um die ganze technische Umsetzung kümmern. Im Team habe ich mich dieser Aufgabe gestellt. In meinem Blog-Beitrag möchte ich euch nun meine Erfahrungen mit dem Thema Lasttests aus der Sicht eines Entwicklers in einem agilen Team schildern.

Eine Qualitätssicherung essentieller Bestandteil von Softwareprojekten, denn Risken werden minimiert und die Qualität der Software gesteigert. Da dies immer mit einem gewissem Testaufkommen oder Testaufwand verbunden ist, bietet sich eine Testautomatisierung an. In unserem Blog-Beitrag möchten wir euch daher über unsere Erfahrungen mit SoapUI berichten und zeigen, wie wir unsere ersten Meter auf dem Weg des automatisierten Testens erfolgreich gemeistert haben.