Eine Tour durch JavaScript-Komponenten: Testen von Komponenten

In dieser Ausgabe werden wir das Thema JavaScript-Tests besprechen, um zu überprüfen, ob der Status und der Arbeitsmodus von Komponenten wie erwartet sind. Außerdem werden wir eine Testmethode vorstellen, mit der Testfälle einfach geschrieben werden können. Bei den hier erwähnten Tests kommen natürlich automatisierte Testmethoden zum Einsatz, die ein wichtiger Bestandteil der Software-Qualitätssicherung (QS) sind. Was die in dieser Artikelserie vorgestellte Smart Queue betrifft, umfassen unsere Testziele:

• Erstellung von Aufgabenobjekten : Die zweite Phase des Codes bietet verschiedene Erstellungsmethoden und es ist notwendig, den Status des Objekts nach der Erstellung zu testen.
• Ausführungsreihenfolge der Aufgabe innerhalb der Warteschlange : Wir bieten zwei Möglichkeiten, die Ausführungsreihenfolge zu ändern: Prioritäts- und Abhängigkeitskonfiguration. Wir müssen auch die Auswirkungen verschiedener Konfigurationen auf die Reihenfolge testen.

Überprüfen Sie für das erste Ziel einfach, ob die Eigenschaften des Objekts nach der Erstellung den Erwartungen entsprechen. Wir haben schon oft von „Erwartungskonformität“ gesprochen, und Assert ist dafür konzipiert. Einfach ausgedrückt besteht die Behauptung darin, sicherzustellen, dass der getestete Ausdruck „wahr“ ergibt. Andernfalls wird der Tester auf irgendeine Weise benachrichtigt und ihm dabei geholfen, den Testfall zu finden, bei dem die Behauptung fehlgeschlagen ist.

Das zweite Ziel ist etwas komplizierter. Da wir die sortierte Warteschlange (_sorted) während der Komponentencodierung und -implementierung im Abschluss verstecken, ist sie von außen nicht zugänglich. Es sind zwei Methoden zu berücksichtigen: (1) Refactoring des Codes, um die Testbarkeit des Codes zu erhöhen. Es gibt auch zwei Refactoring-Methoden: (a) Setzen Sie den Debug-Schalter und legen Sie _sorted nach außen offen, wenn er aktiviert ist. Fügen Sie Unabhängigkeitsdateien hinzu und fügen Sie den Code auf Build-Art zusammen, um schließlich eine Testversion zu generieren. (2) Testen Sie die Ergebnisse des Verhaltens und nicht des Prozesses. Die erstere Methode geht im Wesentlichen tief in den Laufzeitstatus der Komponente ein, während diese Methode nur die laufenden Ergebnisse der Komponente überprüft. In dieser Ausgabe wird die letztere Testmethode verwendet, und die erste Testmethode bleibt interessierten Lesern zum Üben überlassen :)

Es ist anzumerken, dass ich persönlich mit der ersten Methode nicht einverstanden bin. Warum? Lassen Sie mich zunächst über das Designkonzept dieser Aufgabenwarteschlange sprechen:

• Es handelt sich lediglich um eine Warteschlange, die nur für die Anpassung der Ausführungsreihenfolge von Aufgaben „auf Abruf“ verantwortlich ist und nicht auf die einzelnen Details der Aufgaben achtet. Mit anderen Worten: Es bearbeitet die Gesamtaufgabe, ohne sich um aufgabenspezifisches Verhalten und Leistung zu kümmern.
• Es handelt sich um eine sichere Warteschlange. Benutzer (die in der ersten Ausgabe erwähnten „Kunden“) können ihr Aufgaben hinzufügen, ohne befürchten zu müssen, dass die Aufgabeninformationen von anderen Kunden gesehen werden. Es ist zu beachten, dass die zweite Phase des Implementierungscodes SmartQueue.Queue = [[], [], []] enthält. Dadurch kann extern auf die Warteschlangenelemente zugegriffen werden. Der Code dient nur zur Einführung. Sie können SmartQueue.Queue = sicher entfernen, um eine Sicherheitskontrolle zu erreichen.

Quelle: Alipay UED