Java >> Java Tutorial >  >> Java

Java Test Weekly 28 / 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

  • JMockit 101 ist der erste Teil des JMockit-Tutorials von baeldung und bietet eine praktische Einführung in JMockit. Sie lernen, Erwartungen zu spezifizieren und Mock-Objekte mit JMockit zu erstellen. Das Interessanteste an JMockit ist, dass es eine völlig andere API als mockito hat. Ich bin mir nicht sicher, ob es mir gefällt, aber ich denke, dass es gut ist, dass wir mehrere verschiedene Mocking Frameworks haben.
  • JUnit 5 M1 gibt die Veröffentlichung von JUnit 5 M1 bekannt. Das erste Meilenstein-Release konzentrierte sich auf die Bereitstellung stabiler APIs für IDEs und andere Build-Tools. Außerdem enthielt es eine neue Funktion namens dynamische Tests. Wenn Sie mehr über dynamische Tests erfahren möchten, sollten Sie diesen Blogbeitrag lesen.
  • Robot Framework Tutorial 2016 – Integration with Jenkins beschreibt, wie Sie Robot Framework mit dem Jenkins CI-Server integrieren können. Dieser Beitrag enthält Schritt-für-Schritt-Anleitungen und viele Screenshots. Mit anderen Worten, Sie sollten in der Lage sein, die Arbeit zu erledigen, solange Sie die Anweisungen befolgen.
  • Das Testen mit Hamcrest ist im Grunde ein Spickzettel, der beschreibt, wie Sie verschiedene Hamcrest-Matcher verwenden können. Dieser Beitrag ist sowohl für Anfänger als auch für fortgeschrittene Benutzer nützlich, da er als "Referenzhandbuch" verwendet werden kann.

Das wirklich Wertvolle

  • Testumgebungen und organisatorische Aspekte ist ein wirklich interessanter Beitrag, weil er zwei Geschichten erzählt. Die erste Geschichte beschreibt die Vor- und Nachteile der Verwendung von Mocks und Stubs zum Isolieren des zu testenden Systems von seinen Abhängigkeiten. Der zweite beschreibt, wie organisatorische Aspekte Ihre Wahlmöglichkeiten einschränken oder erweitern können. Die zweite Geschichte ließ mich erkennen, wie glücklich ich bin, wenn ich für ein Unternehmen arbeite, das keine Angst davor hat, Geld auszugeben. Es gibt im Grunde "null" Bürokratie und ich habe das Gefühl, dass unsere IT-Abteilung für mich arbeitet. All das fühlt sich für mich so selbstverständlich an, dass ich immer wieder überrascht bin, dass nicht alle Unternehmen so handeln.
  • The Tester and Technical Debt ist ein großartiger Beitrag, weil er einen hervorragenden Einblick bietet:Technische Schulden entstehen normalerweise zufällig. Die Sache ist, dass die meisten von uns nicht entscheiden, dass heute der Tag ist, an dem wir technische Schulden schaffen. Stattdessen treffen wir jeden Tag kleine Entscheidungen und stellen eines Tages fest, dass unsere Codebasis nicht so gut ist, wie sie sein sollte. Wenn wir das erkennen, übernehmen wir keine Verantwortung für unsere Handlungen. Wir nennen es einfach technische Schulden und „machen weiter“. Ich denke, es ist ironisch (und äußerst befriedigend), dass dieser Beitrag die beste Beschreibung technischer Schulden liefert, die ich je gelesen habe. Und es wurde von einem Tester geschrieben.
  • Sollten Entwickler Akzeptanztests besitzen? argumentiert, dass Akzeptanztests im Besitz des Teams sein sollten. Ich denke, dass dies aus zwei Gründen eine gute Idee ist:Erstens , Entwickler haben normalerweise keine Zeit, alles zu besitzen, und wenn Entwickler Akzeptanztests besitzen würden, würden sie sie wahrscheinlich nicht schreiben. Zweiter , Tester sind gut im Entwerfen von Testfällen und möchten normalerweise nicht alles automatisieren. Wenn Entwickler Abnahmetests besitzen würden, würden sie diese wahrscheinlich automatisieren und das ist nicht immer eine gute Sache.
  • We Are Not Gatekeepers ist ein ausgezeichneter Beitrag, der beschreibt, warum Tester nicht für die Qualitätssicherung verantwortlich sind und nicht entscheiden, wann etwas in der Produktion bereitgestellt werden kann. Ich bin mir nicht sicher, warum manche Leute das nicht verstehen, aber ich vermute, dass diese Leute keine Verantwortung für ihre Handlungen und Entscheidungen übernehmen wollen. Stimmen Sie zu?

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 uns 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 Blogpost auf Twitter teilen.

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


Java-Tag