Java Test Weekly 20 / 2017

Es gibt viele Blogs zur Softwareentwicklung, aber viele von ihnen veröffentlichen nicht regelmäßig Testartikel.

Außerdem ist mir aufgefallen, dass einige Softwareentwickler keine Blogs lesen, die von Softwaretestern geschrieben wurden.

Das ist schade, denn ich denke, dass wir viel von ihnen lernen können.

Aus diesem Grund habe ich beschlossen, einen Newsletter zu erstellen, der die besten Testartikel teilt, die ich in der letzten Woche gefunden habe.

Fangen wir an.

Technisches Zeug

Mein Problem mit dem Drehbuchmuster ist ein interessanter Beitrag, der davon ausgeht, dass Sie Erfahrung mit dem Schreiben von End-to-End-Tests haben. Auf jeden Fall erklärt der Autor, wie das Drehbuchmuster mit Ihren Seitenobjekten koexistieren sollte, und beschreibt, wie Sie Ihren Testcode organisieren sollten, wenn Sie sich für diesen Ansatz entscheiden.
TDD mit Spock, Groovy und Java bietet eine sehr schnelle Einführung in TDD und beschreibt, wie Sie Komponententests für Java-Code mit Spock Framework schreiben können.
Das Testen von Spring Data + Spring Boot-Anwendungen mit Arquillian (Teil 2) verbessert den im ersten Teil dieses Tutorials beschriebenen Integrationstest. Genauer gesagt erklärt dieser Beitrag, wie Sie Testdaten in die verwendete Redis-Instanz einfügen können, indem Sie die Arquillian Persistence Extension (APE) verwenden.
Die Tragödie von 100 % Codeabdeckung bietet zwei Beispiele, die zeigen, was passieren kann, wenn Sie ein Codeabdeckungsziel haben (es muss nicht 100 %) sein oder wenn Sie sinnlose Tests schreiben, nur weil Ihr Chef es Ihnen befohlen hat es.

Fünf-Faktoren-Testen ist ein sehr interessanter Beitrag, der fünf Gründe (Faktoren) identifiziert, warum Entwickler normalerweise Tests schreiben, und erklärt, wie Sie diese Faktoren als Rahmen verwenden können, der Ihnen hilft, nützliche Diskussionen über Ihre Teststrategie zu führen.
Beachten Sie, was Ihre Tests zu überprüfen versuchen, beschreibt, warum Sie (fast) immer End-to-End-Tests schreiben sollten, die das Verhalten eines echten Benutzers nachahmen. Mit anderen Worten, dieser Beitrag erklärt, warum es keine gute Idee ist, Ihren Test dazu zu "zwingen", etwas zu tun, was Ihre Benutzer nicht tun können.