Wie Softwaretests zur Kommunikation beitragen können

Softwaretests können die Kommunikation verbessern und Zeit (und Frustration) sparen. Schlechte Tests können das Gegenteil bewirken. In diesem Artikel werden wir anhand eines Beispiels aus dem wirklichen Leben untersuchen, wie schlechte Tests schädlich sind und wie gute Tests die richtigen Informationen vermitteln.

Ein Märchen über einen Titel

Unter Lebendigmussten wir einen Titel zu unserer Schaltfläche. Es ist nicht so, dass die Schaltfläche keinen gehabt hätte. Vivid ist eine auf Webkomponenten basierende Bibliothek, und in unserem Schaltflächenelement befindet sich eine versteckte native Schaltfläche unter dem Schatten-DOM.

Diese native Schaltfläche erhielt nicht den Titel der übergeordneten Schaltfläche, was für die Barrierefreiheit unserer Website schlecht war (basierend auf a11y Standards).

Also... die Aufgabe war ziemlich einfach. Holen Sie sich einen Titel vom Host (das benutzerdefinierte Element) und spiegeln Sie ihn auf die interne Schaltfläche. Einfach so:

Wir werden dieses Beispiel verwenden und seinen Commit-Pfad verfolgen, um zu verstehen und zu lernen, wie man einfache Fehler beim Testen vermeiden kann.

Lektion 1: Eine Änderung der Schnittstelle ist ein Warnsignal

Der erste Commit in diesem Pull Request hat sich in die Schnittstelle eingemischt. Hier ist die Änderung im Test:

Dies führte dazu, dass die Tests fehlschlugen. Sie können sehen, dass sich der Test von toBeFalsy zu "gleich einer leeren Zeichenkette sein". Was ist daran falsch?

In diesem Fall liegen drei Fehler vor:

• toBeFalsy kann vieles sein (leerer String, null, undefined, NaN, 0 und false), aber im Gegensatz zu einer leeren Zeichenkette ist sie nicht unbegrenzt.

• Die Schnittstelle wurde nicht gut genug dokumentiert, weil toBeFalsy zu breit ist.

• Die Schnittstelle wurde im Test aus irgendeinem Grund in '' geändert. Was ist der Grund dafür? Handelt es sich um eine schwerwiegende Änderung?

Hier verdichtet sich die Handlung. Diese beiden Fehler sind nur die Vorspeisen für einen Verlust von 24 Stunden Entwicklung. Kommen wir zum Hauptgericht.

Wie schlechte Tests zu schlechtem Code führen

Während ich versuchte, den fehlgeschlagenen Test zu korrigieren, befand ich mich auf dem Rückweg von einem Urlaub.

Ich habe mir den Testcode mit meinem Telefon angesehen und festgestellt, dass die dokumentierte Schnittstelle impliziert, dass der Titelwert ein leerer String sein sollte.

"Natürlich schlägt es fehl! Der Anfangswert ist keine leere Zeichenkette. Setzen Sie ihn einfach auf eine leere Zeichenkette, und es wird funktionieren."

Die Änderung war ziemlich einfach. Legen Sie einfach den Wert im Konstruktor fest, und der Test wird bestehen:

Diese Korrektur verschlimmerte das Problem, das wir beim ersten Fehler festgestellt hatten. Wir haben nicht nur die Dokumentation geändert, sondern auch die eigentliche Schnittstelle. Ja, die Tests wurden bestanden, aber war es der richtige Test? Und wieso hat uns eine so einfache Sache 24 Stunden Arbeit gekostet? Kommen wir nun zum zweiten Fehler.

Fehler Nr. 2: Du sollst nicht passen (aus dem richtigen Grund)

Die Änderung der Schnittstelle war nur der erste Schritt. Die eigentliche Logik musste noch implementiert werden, oder? Hier ist der Test für die nächste Implementierung:

Das erste, was auffällt, ist die Beschreibung des Tests. Der Tippfehler (fehlender Satz nach "not") ist der auffälligste Fehler, aber es gibt noch etwas anderes.

Die Beschreibung ist in negativer Form geschrieben. In der Wissenschaft kann man nicht beweisen, dass etwas nicht existiert. Da Software in den Bereich der Informatik fällt, können wir sie auch so betrachten. Sagen Sie mir nicht, was sie nicht tun sollte - sagen Sie mir, was sie tun sollte.

Zwei Dinge, die noch schlimmer sind als die Beschreibung, befinden sich im Testcode selbst. Nehmen Sie sich eine Minute Zeit, um zu sehen, ob Sie sie finden.

...

...

Okay, die Minute ist um. Haben Sie noch ein oder zwei Fehler gefunden?

Falscher Grund Nr. 1: Testen der falschen Sache

Ich habe eingangs erwähnt, dass unsere Aufgabe darin bestand, den Titel auf der internen Schaltfläche zu setzen. Dieser Test beschreibt dieses Szenario nicht.

Können Sie sehen, dass der Test am Element und nicht an der internen Schaltfläche durchgeführt wird? Als ich den Test las, nahm ich an, dass der Autor wollte, dass der Titel auf dem Element erscheint. So steht es in der Dokumentation. Und das ist es, was ich von der Komponente erwarte.

Falscher Grund Nr. 2: Die Erwartung stimmt nicht mit der Beschreibung überein

Eine andere Sache ist, dass in diesem Test ein Titel mit einer leeren Zeichenkette erwartet wird. Was wir erreichen wollen, ist etwas ganz anderes - wir wollen in einem solchen Fall das Attribut title entfernen.

12 Stunden vergingen, und ich war aus dem Urlaub zurück und überlegte, wie ich den Code so implementieren könnte, dass er den vorgegebenen Spezifikationen entsprach.

Einige Slack-Nachrichten bestätigten meinen Verdacht - das title-Attribut sollte entfernt werden, wenn der Titel falsy ist. Ich habe nicht eine Minute lang daran gezweifelt, dass der Titel nicht auf das Element gesetzt werden sollte.

Ich habe den Test ein wenig geändert, um sicherzustellen, dass wir auf dem richtigen Weg sind:

t

Die Erwartung ist nun, das Attribut tatsächlich zu entfernen.

Damit es funktioniert, musste ich ein paar Dinge in der Vorlage und der Klasse der Komponente ändern. In der Klasse musste ich das Attribut title überschreiben (unser Class erweitert ein anderes Basiselement Class). Ich musste auch einen Konverter festlegen, der den Wert in der Vorlage auf null setzt, wenn der Wert falsy ist, aber lassen Sie es als eine Zeichenfolge, wenn von der Ansicht selbst geändert:

Alles funktionierte wie erwartet. Ich drängte und erwartete das Lob der PR-Autorin, wie ich ihren Tag gerettet habe. Oder... nicht?

Kommunikation ist der Schlüssel

Die erwartete Slack-Nachricht kam ein paar Stunden später. Die Nachricht selbst war allerdings weniger erwartet:

Moment, WAT?!?

Und so begann eine weitere Slack-Korrespondenz. Es war eine kurze Korrespondenz, aber am Ende war das meine Meinung:

Ich war schockiert, als sich herausstellte, dass das Problem mit der internen Taste zusammenhing.

Die Lösung war, wie erwartet, minimal. Ich musste den Test sowohl für das Element als auch für die interne Schaltfläche durchführen (wir nennen solche Elemente "Steuerelemente"):

Da wir nun einen Test durchgeführt haben, können wir auch sicherstellen, dass unser Anfangswert spezifischer ist und den HTML-Spezifikationen entspricht (null):

Für diese einfache Reparatur haben wir 24 Stunden gebraucht (ja, ich weiß, dass ich die Hälfte dieser Zeit im Urlaub war, aber Ausreden sind etwas für Schwächlinge 😉 ). Mit besseren Tests oder besseren Kommunikationsfähigkeiten meinerseits hätte man es sich sparen können.

Schlussfolgerung

Gute Tests schreiben

Tests sollen fehlschlagen, wenn Ihr Code nicht tut, was er tun soll. Tests sollen auch eine direkte Beschreibung der Funktionsweise Ihres Codes sein. Wenn der Test sagt, dass ein Titel auf dem Element sein sollte, dann sind dies die Anweisungen für den Implementierer.

Die Schnittstelle wird auch durch Tests überwacht. Wenn der Test die Schnittstelle nicht richtig oder nicht eng genug schützt (wie in der toBeFalsy anstelle von toBeNull Beispiel hier), dann wissen wir nicht wirklich, was wir als Entwickler und Nutzer der Schnittstelle erwarten können. Mehr über die Bedeutung von Schnittstellentests können Sie in meinem Beitrag lesen, A Tale of Implementation and Detail.

Tests schreiben, um zu kommunizieren

Gute Kommunikationsfähigkeiten sind wichtig. Nicht jeder hat sie. Vor allem nicht in einer entfernten Arbeitsumgebung. Hätten wir persönlich zusammen programmiert, hätte das vielleicht nicht so lange gedauert. Unser Team arbeitet aus der Ferne (ein internationales Team), und die Kommunikation erfolgt in der Regel "asynchron", d. h., es gibt normalerweise eine Verzögerung bei der Antwort.

Das korrekte Schreiben der Tests mit einer klaren Beschreibung und einer Logik, die beschreibt, wie die Dinge ablaufen sollten, trägt dazu bei, solche Kommunikationsfehler im Team zu verringern.

Beteiligen Sie sich am Gespräch auf unserem Vonage Community Slack oder senden Sie uns eine Nachricht auf X, früher bekannt als Twitter.