Java >> Java Tutorial >  >> Java

Java Test Weekly 6 / 2016

Java

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

  • Effektive Assertionen, von Java bis Scala beginnen mit der Beschreibung der kurzen Geschichte verschiedener Assertion-Stile, die in (J)Unit-Tests zu finden sind, und geben einen kurzen Blick in die Zukunft, indem sie einen Blick auf verschiedene Assertion-Bibliotheken werfen, die verwendet werden können Schreiben von Unit-Tests für Scala-Code. Ich finde diesen Blogbeitrag extrem faszinierend, weil ich den gleichen Weg wie der Autor gegangen bin und das Lesen dieses Blogbeitrags viele (wahrscheinlich peinliche) Erinnerungen zurückgebracht hat.
  • FitNesse in your IDE gibt die Veröffentlichung des Fitnesse-Plugins für IntelliJ Idea bekannt. Fitnesse wurde 2001 von Uncle Bob erstellt, und anscheinend ist dies das erste IDE-Plugin, das Fitnesse unterstützt. Das klingt für mich ein bisschen verrückt. Wie auch immer, wenn Sie Fitnesse und IntelliJ Idea verwenden, sollten Sie sich dieses Plugin ansehen.
  • Introduction to Spring REST Docs beschreibt, wie Sie Ihre REST-API dokumentieren können, indem Sie Integrationstests mit Spring Test MVC schreiben. Dieser Blogbeitrag enthält die Informationen, die Sie für den Einstieg in Spring Rest Docs benötigen, und enthält auch eine funktionierende Beispielanwendung. Übrigens, wenn Sie Rest-assured verwenden, freuen Sie sich wahrscheinlich zu hören, dass Spring Rest Docs es in Zukunft unterstützen wird.
  • Robot Framework und der schlüsselwortgesteuerte Ansatz zur Testautomatisierung – Teil 2 von 3 bietet eine umfassende Einführung in Robot-Schlüsselwörter, identifiziert die Risiken von schlüsselwortgesteuerten Tests und hilft Ihnen, diese Risiken zu vermeiden. Ich mag dieses Tutorial, weil es die "Theorie" hinter schlüsselwortgetriebenem Testen beschreibt, bevor es zeigt, wie Sie es tatsächlich tun können. Auf diese Weise können Sie beurteilen, ob Keyword-basiertes Testen für Sie nützlich ist oder nicht. Wenn Sie sich entscheiden, diesen Beitrag zu lesen, sollten Sie wahrscheinlich auch den ersten Teil dieses Tutorials lesen, bevor Sie diesen Blog-Beitrag lesen.

Das wirklich Wertvolle

  • Agiles Testen:Frustrationen können uns zu kreativen Antworten auf diese beiden Fragen führen:1) Wer sollte in einem agilen Team manuelle Tests durchführen? 2) Wann sollte diese Prüfung stattfinden? Das sind wichtige Fragen und ich denke, dass wir (Entwickler) unseren Teil dazu beitragen müssen. Tatsächlich ist eines meiner größten Probleme, dass ich nicht mit einem Tester arbeiten kann, weil wir keine Tester haben. Ich wette, dass es Spaß machen würde, sich mit einem Tester zusammenzuschließen und herauszufinden, welche Art von (manuellen) Tests ich für meinen Code durchführen sollte. Sicher, ich teste immer, ob mein Code "funktioniert", aber ich sauge an explorativem Testen. Ich weiß, dass ich nie ein Experte sein werde, aber es wäre nützlich, die Grundlagen zu kennen. Außerdem wäre es interessant, eine zweite Meinung zu meinen wertvollen Unit- und Integrationstests einzuholen.
  • Unterstützung bei Anfragen:Teil drei – Filtern von Informationen hilft Ihnen zu verstehen, warum Sie Informationen filtern sollten, bevor Sie sie verschiedenen Zielgruppen melden. Die Sache ist die, dass unterschiedliche Leute an unterschiedlichen Dingen interessiert sind und uninteressante Informationen trotzdem herausfiltern. Wenn Sie Ihre Botschaft intakt halten möchten, müssen Sie Informationen bereitstellen, die für Ihr Publikum relevant sind, und dieser Blogbeitrag hilft Ihnen dabei.
  • Best Practices für Wiederherstellungstests beschreibt, warum Sie sich um Wiederherstellungstests kümmern sollten, und bietet solide Beispiele, die Ihnen dabei helfen, Wiederherstellungstests für reale Anwendungen durchzuführen. Ich denke, dass Erholungstests extrem wichtig sind. Leider habe ich auch ein "Bauchgefühl", das sagt, dass es auch extrem selten ist. Da ich jedoch ein optimistischer Mensch bin, hoffe ich, dass dieser Blogbeitrag die Menschen dazu motiviert, zumindest die Notwendigkeit von Erholungstests zu erkennen. Es ist nicht viel, aber es ist ein Anfang.
  • Test-Mythos Nr. 2:Unit-Tests lohnen sich nicht widerlegt den Mythos, dass es sich nicht lohnt, Unit-Tests zu schreiben. Ich stimme dem Autor zu, und ich möchte hinzufügen, dass ein möglicher Grund, warum Entwickler diesen Mythos am Leben erhalten, darin besteht, dass sie einfach nicht wissen, wie man gute Unit-Tests schreibt, und sich zu sehr schämen, dies zuzugeben.
  • What Flaky Tests Can Tell You argumentiert, dass fehlerhafte End-to-End-Tests Leistungsprobleme, Bugs, Teamwork-Probleme und Kommunikationsprobleme aufdecken können. Dieser Beitrag macht einige interessante Punkte, weil Entwickler normalerweise denken, dass nicht-deterministische Tests schädlich sind, weil sie so viele Fehlalarme verursachen, dass Entwickler ihrer Testsuite nicht mehr vertrauen (denken Sie daran, was mit dem Jungen passiert ist, der Wolf rief). Häufig werden nicht deterministische Tests entweder ignoriert oder gelöscht. Früher dachte ich, dass dies ein guter Weg ist, mit ihnen umzugehen, aber ich habe meine Meinung geändert, nachdem ich diesen Blogbeitrag gelesen hatte. Ich denke immer noch, dass es in Ordnung sein könnte, sie zu löschen, aber zuerst sollten wir sicherstellen, dass dieses Verhalten nicht durch einen Fehler oder ein Leistungsproblem verursacht wird.
  • Wer testet Ihre Komponententests? adressiert das folgende Argument:"TDD ist standardmäßig fehlerhaft, da niemand Ihre Komponententests testet" . Ich muss zugeben, dass mir dieser Blogbeitrag zwar gefällt, ich mir aber ziemlich sicher bin, dass mir die Argumentation nicht gefällt. Um ehrlich zu sein, klingt es wie eine Entschuldigung, etwas nicht zu tun, was die Person nicht tun möchte. Ich denke, der Autor des Posts macht viele gute Punkte, und ich möchte meine eigene Meinung hinzufügen:Wenn Ihre Tests so komplex sind, dass Sie sie testen müssen, schreiben Sie beschissene Tests. Teilen Sie Ihre Tests in kleinere Tests auf, die besser lesbar sind und weniger Fehler enthalten. Dies wird Ihnen helfen, Tests zu schreiben, die die Anforderungen des zu testenden Systems spezifizieren.

Es ist Zeit für Feedback

Weil ich möchte, dass dieser Newsletter Ihre Zeit wert ist, bitte ich Sie, mir dabei zu helfen, ihn zu verbessern.

  • Wenn Sie Feedback zu diesem Newsletter haben, teilen Sie Ihre Gedanken im Kommentarbereich mit.
  • Wenn Sie einen Blogbeitrag über automatisiertes Testen oder Softwaretests geschrieben haben, pingen Sie mich auf Twitter an.
  • Sie können diesen Blogbeitrag auf Twitter teilen.

P.S. Wenn Sie sicherstellen möchten, dass Sie Java Testing Weekly nie verpassen, sollten Sie meinen Newsletter abonnieren.


Java-Tag