Java >> Java Tutorial >  >> Java

Java Testing Weekly 4 / 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

  • Angular Testing Part 3:Testing Recipes hilft Ihnen beim Schreiben von Tests für AngularJS-Controller, -Dienste und -Anweisungen. Ich weiß aus Erfahrung, dass es sehr einfach ist, Ausreden dafür zu finden, keine Tests für Frontend-Code zu schreiben (insbesondere wenn Sie ein "Backend-Entwickler" sind). Da Sie jedoch früher oder später damit beginnen müssen, können Sie es genauso gut früher tun. Sie können beginnen, indem Sie diesen Blogbeitrag lesen. Denken Sie auch daran, den ersten und zweiten Teil dieses Tutorials zu lesen.
  • Codeabdeckung mit Gradle und JaCoCo beschreibt, wie Sie Codeabdeckungsberichte mit Gradle und JaCoCo erstellen können (Wenn Sie Maven verwenden, lesen Sie diesen Blogbeitrag). Eine Warnung jedoch:Die Codeabdeckung ist eine schreckliche Methode, um die Qualität Ihrer Testsuite zu messen. Verwenden Sie es nicht für diesen Zweck. Wenn Sie jedoch die Teile Ihrer Anwendung identifizieren müssen, die nicht ordnungsgemäß getestet wurden, kann Ihnen die Codeabdeckung dabei helfen, dieses Ziel zu erreichen.
  • How a Smell in the Tests Points to a Risk in the Design beschreibt, wie ein doppelter Methodenparameter ein Problem identifizieren kann, das im Design des getesteten Codes gefunden wurde. Das war das erste Mal, dass ich von dieser Idee hörte. Es ist eine Schande, denn wenn man darüber nachdenkt, ergibt es Sinn.
  • Writing Unit Tests With Spock Framework:Introduction to Specifications, Part Two beschreibt die Struktur einer Feature-Methode und hilft Ihnen, Ihre ersten Feature-Methoden zu schreiben. Wenn Sie es leid sind, Testcode mit Java zu schreiben, sollten Sie sich Groovy und Spock Framework ansehen. Dieser Blogbeitrag hilft Ihnen beim Einstieg.
  • Mocking HTTP Interaction with Java, JUnit and MockServer beschreibt, wie Sie HTTP-Antworten mit JUnit und MockServer simulieren können. Dies ist eine äußerst nützliche Technik, wenn Sie den getesteten Code von einer externen API isolieren müssen. Sie sollten diese Technik jedoch mit Vorsicht verwenden, da diese Tests Ihnen nicht dabei helfen, Fehler zu erkennen, die durch die vom API-Anbieter vorgenommenen Änderungen verursacht wurden.
  • Verwenden Sie erwartete Ausnahmen von JUnit sparsam ist eine fast legendäre Tirade von Lukas Edes (dem Schöpfer von jOOQ). Ich stimme ihm fast zu (ich verwende die @ExpectedException Anmerkungen), aber ich denke, dass er einen sehr wichtigen Punkt hat:Wenn alle Tests eines Projekts denselben Ansatz verwenden, ist es sehr wahrscheinlich, dass der Autor des Projekts denkt, dass dies der beste Weg ist, sie zu schreiben. Sollten Sie versuchen, sie/ihn umzustimmen? Sie können, aber die Chancen stehen gut, dass Sie nur die Zeit aller verschwenden.

Das wirklich Wertvolle

  • Unterstützung bei Anfragen:Teil eins – Ihre Zielgruppe ist ein äußerst wichtiger Blogbeitrag, der Ihnen hilft, Informationen mit den Interessenvertretern Ihres Softwareprojekts auszutauschen. Es hilft Ihnen, diese Personen in verschiedene Gruppen einzuteilen und eine maßgeschneiderte Nachricht für jede Gruppe zu erstellen. Ursprünglich dachte ich, dass dieses Tutorial über das Testen spricht, aber als ich diesen Blogbeitrag las, wurde mir klar, dass Sie diesen Ansatz jedes Mal verwenden müssen, wenn Sie mit Menschen kommunizieren. Ich fordere Sie auf, Ihren Kollegen einen Gefallen zu tun und diesen Blogbeitrag zu lesen.
  • Cucumber ist KEIN Testframework! ist ein interessanter Blogbeitrag, der argumentiert, dass Cucumber ein Spezifikationstool ist. Letzte Woche sagte ein Kollege von mir, dass Robot ein Test-Framework ist, und ich stimmte ihm zu. Als ich diesen Blogbeitrag las, wurde mir jedoch klar, dass eine Spezifikation und ein automatisierter Test (oder eine Überprüfung) zwei sehr unterschiedliche Dinge sind. Wieso den? Wenn Sie eine Antwort auf diese Frage finden möchten, sollten Sie diesen Blogbeitrag lesen.
  • Test-Mythos Nr. 1:Das Schreiben von Tests verlangsamt dich ist ein wichtiger Beitrag, der erklärt, dass das Schreiben von Tests dich nur verlangsamt, wenn du an kurzfristige Kosten denkst (d. h. du willst diesen Scheiß so schnell wie möglich erledigen), du hast Sie haben nicht viele Tests geschrieben, oder Sie schreiben Ihre Tests auf dem falschen Niveau. Ich stimme zu. Wenn Sie keine Tests für Ihren Code schreiben, erweisen Sie der armen Seele, die Ihren Code in Zukunft pflegen muss, einen großen Bärendienst. Willst du wirklich als die Person in Erinnerung bleiben, deren Name als Erkennungszeichen für beschissenen Code verwendet wird?
  • Veraltetes Testkonzept Nr. 2:Der heilige Qualitätswächter widerlegt den Mythos, dass Tester für die Produktqualität verantwortlich sind. Der Autor argumentiert, dass eine einzelne Person (Entwickler, Tester oder Manager) nicht für die Qualität des Endprodukts verantwortlich sein kann. Stattdessen schlägt er vor:"Jeder wertet das Produkt mit seinen einzigartigen Fähigkeiten auf und trägt die Verantwortung für die Folgen seiner Fehler" . Es ist schwer, dem zu widersprechen, und um ehrlich zu sein, möchte ich das auch gar nicht.
  • Understanding How To Do Accessibility Testing ist ein Blogbeitrag, bei dem ich mich (ein bisschen) für mich selbst beschämt habe. Der Grund, warum ich so reagiert habe, ist, dass noch nie jemand Barrierefreiheitstests für die von mir geschriebene Software durchgeführt hat, und dieser Blogbeitrag hat mich daran erinnert, dass dies wahrscheinlich bedeutet, dass es Leute gibt, die "meine Software" einfach nicht verwenden können. . Es wäre ganz einfach zu sagen:"Es ist nicht meine Schuld, weil...". Ich werde dies nicht tun, weil ich stolz auf meine Arbeit sein möchte und anderen Menschen die Schuld zu geben, wird mir nicht helfen, dieses Ziel zu erreichen. Stattdessen entschied ich mich, mehr über Barrierefreiheit zu erfahren. Wo soll ich anfangen?

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