Java >> Java Tutorial >  >> Java

Java Testing Weekly 17 / 2016

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

  • Erste Schritte mit JavaScript-Tests mit Jasmine bietet eine schnelle Einführung in Jasmine, das zum Schreiben von Tests im BDD-Stil für Javascript-Code verwendet wird. Dieser Blogbeitrag ist nützlich für Personen, die noch nie Tests für Javascript-Code geschrieben oder Jasmine noch nie verwendet haben.
  • Wie ich mit automatisierten Tests Frieden geschlossen habe. Teil 1 — You’re Using Too Many Mocks“ erzählt die Geschichte eines Entwicklers (des Autors), der keine automatisierten Tests schreiben wollte, weil dies viel Arbeit erforderte und zu viel Zeit in Anspruch nahm. Zum Glück hat diese Geschichte ein Happy End. Der Entwickler erkannte, dass er zu viele Scheinobjekte verwendete. Als er aufhörte, zu viele Scheinobjekte zu verwenden, fing er an, gerne automatisierte Tests zu schreiben.
  • Sparen Sie Zeit, indem Sie weniger Testcode schreiben kündigt meinen bevorstehenden Test mit Frühlingskurs an. Das Ziel dieses Kurses ist es, Ihnen beim Schreiben automatisierter Tests für Spring-Webanwendungen zu helfen, und er beschreibt, wie Sie weniger Testcode schreiben können, ohne Ihre Testabdeckung zu opfern. Wenn Sie schnell handeln, können Sie den 50-Prozent-Rabatt nutzen, der am Freitag ausläuft.
  • Das Testen einer zwischenspeicherbaren Methode mit Mockito hilft beim Schreiben eines automatisierten Tests, der sicherstellt, dass die Cache-Abstraktion von Spring Framework wie erwartet funktioniert, wenn Sie eine Methode aufrufen, die mit @Cacheable annotiert ist Anmerkung. Dies ist ein interessanter Blogbeitrag, und ich denke, Sie sollten einen Rauchtest durchführen, der sicherstellt, dass die Cache-Abstraktion 1) richtig konfiguriert ist und 2) wie erwartet funktioniert. Davon abgesehen denke ich, dass Sie keine Tests schreiben sollten, die sicherstellen, dass die Spring-Cache-Abstraktion jede cachefähige Methode zwischenspeichert. Der Grund dafür ist, dass Sie sich auf das Testen Ihres eigenen Codes konzentrieren sollten. Wenn Sie nicht darauf vertrauen, dass Spring Framework (oder ein anderes Tool) wie erwartet funktioniert, sollten Sie es nicht verwenden.
  • Warum ein Builder-Muster verwenden? Beispiele für teleskopierende Konstruktoren beim Speichern von Adressdaten identifiziert die Probleme, die durch das (Anti-)Muster des teleskopierenden Konstruktors verursacht werden, und beschreibt, wie Sie sie mithilfe des Builder-Musters lösen können. Ich denke, dass das Builder-Muster ein äußerst nützliches Werkzeug zum Erstellen von Testdaten ist, aber Sie sollten es nicht übermäßig verwenden, da es nicht kostenlos ist.

Das wirklich Wertvolle

  • Approaching Zero Bugs ist ein interessanter Blogbeitrag, der beschreibt, wie der Autor Entwicklern dabei geholfen hat, ihre Testfähigkeiten zu verbessern und Continuous Delivery durchzuführen, ohne viele automatisierte Tests schreiben zu müssen. Ich muss zugeben, dass das ein bisschen riskant klingt. Andererseits, wenn es für sie funktioniert, sollten sie es ändern und anfangen, automatisierte Tests zu schreiben? Außerdem liebe ich die Idee, dass sauberer Code weniger Fehler hat (hauptsächlich, weil ich bemerkt habe, dass er wahr ist).
  • Wie TDD Ihr Team glücklicher machen kann argumentiert, dass TDD Ihr Team aus fünf Gründen glücklicher macht. Dieser Beitrag identifiziert (natürlich) diese fünf Gründe und beschreibt, wie diese Dinge Ihr Leben einfacher machen. Ich denke, dass der Autor definitiv Recht hat, aber ich bezweifle, dass dieser Blogbeitrag widerstrebende Entwickler davon überzeugen wird, mit TDD zu beginnen. Der Grund dafür ist, dass die meisten Leute damit aufhören, wenn sie die erste Straßensperre treffen (leider bin ich einer von ihnen). Ich schreibe viele automatisierte Tests, aber meistens schreibe ich sie, nachdem ich das Feature fertig gestellt habe. Nun, vielleicht ist es an der Zeit, TDD noch eine Chance zu geben.
  • Testen ist nicht nur eine Phase erklärt, warum das Testen keine Phase zwischen dem Ende der Entwicklung und dem Release ist. Ich mag diesen Blogbeitrag sehr, weil er mir geholfen hat zu erkennen, dass ich im Grunde die ganze Zeit teste. Das mache ich nicht nur bei der Arbeit. In gewisser Weise besteht mein ganzes Leben aus aufeinanderfolgenden Tests. Wenn Sie herausfinden möchten, wie ich zu dieser Schlussfolgerung gelangt bin, empfehle ich Ihnen, diesen Blogbeitrag zu lesen.

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