Ich habe in den letzten zwei Monaten Tests (in JavaScript) geschrieben. Und ich habe die Angewohnheit zu prüfen, ob das Modul einige Eigenschaften hat.
Zum Beispiel:
%Vor%Und ich habe mich gefragt, ob ich die richtigen Dinge tue. Ich möchte nur ein paar Dinge wissen:
Ist dieses Muster "richtig"?
Wenn es nicht "richtig" ist?
Macht es überhaupt Sinn?
Es gibt ein Paradigma mit dem Namen duck typing , das (aus Wikipedia) sagt:
>Bei der Eingabe von Enten geht es einem Programmierer nur darum, das zu gewährleisten Objekte verhalten sich so, wie sie in einem bestimmten Kontext von ihnen verlangt werden, statt sicherstellen, dass sie einer bestimmten Klasse angehören. Zum Beispiel in a Nicht-Ente-typisierte Sprache, würde man eine Funktion erstellen, die erfordert dass das Objekt, das in es hineinging, vom Typ Duck oder vom Typ herstammt Duck, um sicherzustellen, dass diese Funktion das Objekt verwenden kann Spaziergang und Quacksalberei. In einer Ente-typed Sprache würde die Funktion nimm ein beliebiges Objekt und nenne einfach seine Walk- und Quack-Methode, einen Laufzeitfehler erzeugen, wenn sie nicht definiert sind. Anstatt von Arten, die formell festgelegt werden, verlassen sich auf das Schreiben von Enten Dokumentation, klaren Code und Tests, um die korrekte Verwendung sicherzustellen.
Ich würde mich auf den folgenden Teil des obigen Textes konzentrieren:
In einer duckenartigen Sprache würde die Funktion ein beliebiges Objekt annehmen Tippe einfach die Walk- und Quack-Methode und erzeuge eine Laufzeit Fehler, wenn sie nicht definiert sind
Und ...
[...] Verfahren zur Eingabe von Enten beruhen auf Dokumentation, klarem Code und Tests um die korrekte Verwendung sicherzustellen.
Das heißt, da JavaScript eine dynamisch typisierte Sprache ist, passt es sehr gut zur Eingabe von Enten.
Mit anderen Worten sollten Sie diese Tests vermeiden. Wenn ein Modul eine fehlende Eigenschaft hat oder wenn es einen unerwünschten Typ gibt, erhalten Sie einen Laufzeitfehler, der ausreicht, um festzustellen, dass der Aufrufer den impliziten Vertrag nicht erfüllt, um mit a zu funktionieren gegebenes Modul.
Der gesamte Vertrag, der durch das Verhalten Ihres Codes während der Laufzeit definiert wird, kann durch gute Dokumentationsseiten erzwungen werden.
Testen Sie nicht auf Typen. Testen Sie, dass bestimmte Eigenschaftswerte erwarteten Werten entsprechen.
Schreiben Sie also anstelle von "is foo a function" einen Test, der foo aufruft und ein bestimmtes Ergebnis erwartet.
Wenn foo keine Funktion ist, erzeugen Sie einen Fehler und der Test wird fehlschlagen (was gut ist). Wenn foo eine Funktion ist, müssen Sie das Verhalten dieser Funktion testen.
Wenn Sie einen Test schreiben, möchten Sie sicher sein, dass weitere Änderungen des Codes das Verhalten, das Sie testen, nicht ändern.
Es ist also nützlich, wenn Ihr Modul diese Eigenschaft als Schnittstelle verfügbar macht und anderer Code in Ihrer App oder anderen Apps davon abhängt.
Aber wenn das Eigentum, ist nur etwas "Interna", ich meine, es ist nur abhängig von der Modul-Implementierung, als es gefährlich ist und eine Verschwendung von Zeit, wie Sie immer in der Lage sein, Umsetzung zu ändern.
Das gilt nicht für Schnittstellen.
Um zu testen, ob eine Eigenschaft eine Funktion ist, sollten Sie testen, ob die Funktion das tun soll, wenn sie aufgerufen wird.
Wenn es eine Dokumentation gibt, dass diese Funktion eine Schnittstelle des Moduls ist.
Tags und Links javascript testing