Erfahren Sie, wie die Continuous Quality Platform von Parasoft dabei hilft, Testumgebungen zu steuern und zu verwalten, um zuverlässig hochwertige Software zu liefern. Für Demo registrieren >>

BLOG

Schlagen Ihre Unit-Tests fehl und Sie wissen nicht warum?

Schlagen Ihre Unit-Tests fehl und Sie wissen nicht warum? Lesezeit: 5 Minuten
Von den vielen Gründen, aus denen sich Softwareentwickler über Unit-Tests beschweren, ist der Umgang mit lauten Testsuiten einer der größten. Und je länger es eine Software gibt, desto lauter wird sie.

Zur Verdeutlichung meine ich mit "Rauschen" Tests, die ständig fehlschlagen, aber Sie wissen (denken), dass es sowieso in Ordnung ist, also lassen Sie sie einfach sein. Oder Tests, die manchmal fehlschlagen und manchmal funktionieren, aber niemand hat sich jemals die Mühe gemacht, sie herauszufinden oder zu beheben. Und dann gibt es Tests, die zu Recht fehlschlagen, weil sich der Code geändert hat und der Test aktualisiert werden muss. All dieses Geräusch schreit nur nach unserer Aufmerksamkeit, aber der Haken 22 ist, dass je mehr Lärm es gibt, desto weniger wahrscheinlich ist es, dass wir etwas Sinnvolles dagegen tun.

Aber rate mal was? Irgendwo in diesem Geräusch von "fehlgeschlagenen, aber in Ordnung" -Tests gibt es einige echte Probleme, von denen Sie sich wünschen, dass Sie sie kennen. Stellen Sie sich vor, Sie versuchen eine Rechtschreibprüfung. Wenn Sie nicht auf dem Laufenden bleiben, erhalten Sie alle möglichen Dinge, die Sie nicht interessieren, wie spezielle Branchenwörter, Namen usw., die keine wirklichen Rechtschreibprobleme darstellen. Aber irgendwo in diesem Durcheinander verstecken sich die peinlichen Fehler, die Sie tatsächlich gemacht haben - dumme falsch geschriebene Wörter, die Sie da raus wollen. Und natürlich gibt es Tonnen von Rechtschreibfehlern auf der ganzen Welt - aber anders als bei Ihrer Software besteht dort kein großes Risiko, nur eine kleine Verlegenheit.

Dennoch befinden sich Unit-Test-Suiten im Allgemeinen in demselben Zustand. Viele verrauschte Ergebnisse, an die wir uns gewöhnt haben, zu sehen und zu ignorieren, verbergen leider echte Ergebnisse, die wir kennen und verstehen müssen. In vielen Organisationen plant jemand, um dieses Problem zu lösen, einen Sprint, um die Testsuite von Zeit zu Zeit von ein paar Monaten bis zu ein paar Jahren zu bereinigen. Es wird viel Zeit darauf verwendet, die Suite so sauber wie möglich zu gestalten, aber das Problem tritt zwangsläufig sofort wieder auf - und zwar schneller als erwartet. Dies erzeugt eine negative Rückkopplungsschleife - niemand möchte die Tests reinigen, weil er denkt, dass er beim nächsten Mal nur wieder laut wird.

Die Antwort ist ein funktionalerer Ansatz, der mühsame, nutzlose Bereinigungssprints beseitigt und von Anfang an laute Testsuiten vermeidet.

Minimieren von lauten Testsuiten

Dazu ist es wichtig zu verstehen, was es bedeutet, wenn ein Komponententest fehlschlägt. Es läuft auf drei Gründe mit einfachen Korrekturen hinaus:

  1. Der Code ist kaputt. Korrigieren Sie also den Code. (Dies ist im Idealfall das, was saubere Testsuiten Ihnen sagen.)
  2. Der Code wurde ordnungsgemäß geändert und jetzt ist der Test unterbrochen. Korrigieren Sie den Test so, dass er mit dem neuen Code übereinstimmt. (Wenn sich Ihr Code ändert, können Sie davon ausgehen, dass dies geschieht. Ein wichtiger Grund, an Tests zu arbeiten, wenn Sie an dem Code arbeiten.)
  3. Der Test ist falsch und der Code ist in Ordnung. Korrigieren Sie also den Test. (Oder vielleicht entfernen. Aber der Schlüssel ist - ignorieren Sie den Test nicht.)

Jetzt. Sie denken vielleicht - was ist, wenn eine Tonne meiner Testfälle in diese dritte Kategorie passt? Wie ist das eine Hilfe? Also lasst uns das zusammenfassen.

Die Gründe für das Rauschen sind normalerweise einige grundlegende Probleme: schlechte Tests, fragile Tests oder schlechte Behauptungen. Schlechte Tests sind Tests, die ihre Arbeit nicht richtig machen. Entweder testen sie mehr als sie sollten, oder sie hängen an Daten, die inkonsistent sind oder sich aufgrund externer Bedingungen ändern können.

Um das Rauschen zu minimieren, stellen Sie sicher, dass Sie für jeden Test, der Ihnen Probleme bereitet (oder besser noch für alle Ihre Tests), eine gute Antwort auf diese beiden einfachen Fragen haben:

  1. Was bedeutet es, wenn der Test bestanden wird?
  2. Was bedeutet es, wenn der Test fehlschlägt?

Wenn Sie für einen Test keine vernünftige Antwort auf diese beiden Fragen haben, muss er verbessert werden.

Fragile Tests verbessern

Fragile Tests sind solche, die leicht zu brechen sind. Auch dies ist oft ein Symptom für faule Behauptungen - einfach Dinge zu überprüfen, weil sie überprüft werden können, bedeutet nicht, dass sie überprüft werden sollten. Jede Behauptung sollte eine echte Bedeutung in Bezug auf die Anforderung haben, dass der zu testende Code erfüllt. Häufige Schuldige sind datums- / zeitkritische Behauptungen, Betriebssystemabhängigkeiten, Dateinamen- / Pfadabhängigkeiten, Softwareinstallationen von Drittanbietern, Partner-APIs usw. Stellen Sie sicher, dass Sie nur das behaupten, was Sie für einen guten Test nur minimal benötigen, und stellen Sie sicher dass alles, was Sie für den Test benötigen, Teil Ihres Versionsverwaltungs- und Build-Systems ist.

Andere schlechte Behauptungen sind solche, die sich entweder ständig in einem fehlgeschlagenen Zustand befinden, aber es macht Ihnen nichts aus, sie trotzdem freizugeben („Oh, Sie sind in Ordnung, machen Sie sich darüber keine Sorgen“), oder solche, die sich in einem sich ständig ändernden Zustand befinden („ Früher war es in Ordnung und gestern ist es gescheitert, aber heute ist es in Ordnung !! ”). Wenn der Code im Fluss ist, ist es möglicherweise in Ordnung, für kurze Zeit ständig wechselnde Ergebnisse zu erzielen, aber auf lange Sicht sollte dies nicht akzeptabel sein. Sie müssen verstehen, warum sich das Testergebnis ständig ändert oder warum Sie der Meinung sind, dass es in Ordnung ist, zu scheitern und trotzdem zu veröffentlichen. Durch Peer Review Ihrer Komponententests, einschließlich der Behauptungen, kann dieses Problem dauerhaft behoben werden. (Ein zusätzlicher Vorteil von Peer Review? Es ist viel einfacher zu überleben, wenn Sie sich in einer Compliance-Umgebung befinden, in der Tests Teil der vorgeschriebenen Aufsicht sind.)

Die Bewertung fehlerhafter Tests ist wirklich ein großartiger Ort, um den größten Teil Ihrer Bereinigung durchzuführen. Ich fordere Sie auf, sich Tests anzuschauen, die seit Monaten oder sogar Jahren fehlschlagen. Fragen Sie sich, ob sie wirklich einen Mehrwert bieten. Denken Sie daran, Sie ignorieren die Ergebnisse sowieso, also ehrlich, was nützen sie? Durch das Entfernen von Tests, die Sie ignorieren, können Sie sich auf wichtige Tests konzentrieren und Ihre Gesamtqualität verbessern.

Und so wird es ziemlich einfach (obwohl es eine anfängliche Investition von Zeit erfordern könnte). Beachten Sie zum Bereinigen einfach die folgenden Best Practices:

  • Führen Sie regelmäßig Tests durch, damit sie nicht veraltet sind - arbeiten Sie mit dem Code daran.
  • Entfernen Sie Tests, die immer fehlschlagen, oder beheben Sie sie.
  • Entfernen Sie Tests, die den Status ständig umdrehen (bestanden / nicht bestanden), oder ziehen Sie sie fest.
  • Peer-Review-Unit-Tests.

Vergessen Sie natürlich nicht, die mühsame Arbeit mithilfe der Automatisierung zu erledigen, damit die Zeit, die Sie für das Schreiben von Tests aufwenden, produktiver ist und Sie Tests erstellen können, die weniger laut sind.

Verwenden der Testautomatisierung

Durch die Nutzung automatisierter Softwaretests werden Unit-Test-Aufgaben weniger mühsam. Wenn Sie die Automatisierung die einfachen, mühsamen Aufgaben erledigen lassen können (in denen Computer gut sind), können Sie die Dinge tun, die tatsächliche menschliche Intelligenz erfordern (in denen Sie gut sind). Lassen Sie beispielsweise die Automatisierung den ersten Arbeitsdurchgang von Ihnen erstellen xEinheit Testfälle (einfacher Code, dessen Ausführung sehr mühsam wird). Wenn Sie ein Tool Ihre Getter / Setter-Testmethoden automatisch generieren lassen, können Sie Tonnen von Zeit sparen, die Sie für andere, interessantere Dinge verwenden können.

Wenn wir mit der Testautomatisierung ausgeklügelter werden, können Tools noch weiter helfen und einige der kniffligeren Teile des Unit-Tests erledigen, wie z. B. das Erstellen und Konfigurieren von Stubs und Mocks. Je mehr Sie die Vorteile der Automatisierung nutzen, desto weniger Zeit wird das Testen von Einheiten in Anspruch nehmen – und es wird auch viel weniger langweilig sein. Wenn Sie Java verwenden, werfen Sie einen Blick auf die Parasoft Unit-Testing-Lösung. Es macht all diese Dinge und noch viel mehr und macht Unit-Tests nicht nur einfacher, sondern auch viel angenehmer.

Automatisieren Sie die Erstellung von JUnit-Tests und lieben Sie Unit-Tests

Geschrieben von

Artur Hicken

Arthur ist seit über 25 Jahren bei Parasoft im Bereich Software-Sicherheit und Testautomatisierung tätig. Er hilft bei der Erforschung neuer Methoden und Techniken (einschließlich 5 Patente) und hilft Kunden dabei, ihre Software-Praktiken zu verbessern.

Erhalten Sie die neuesten Nachrichten und Ressourcen zum Testen von Software sofort.