Erklären Sie Unit-Tests bitte

Sie haben Ihre Erwartungen an Unit-Tests erfüllt. Es geht sehr viel darum, das erwartete Verhalten zu validieren und zu überprüfen.

Ein Wert, den viele Leute bei Unit-Tests vermissen, ist, dass ihr Wert mit der Zeit zunimmt. Wenn ich ein Stück Code schreibe und einen Komponententest schreibe, habe ich im Grunde nur getestet, dass der Code das tut, was er meiner Meinung nach tun sollte, dass er nicht in irgendeiner Weise versagt, in der ich überprüft habe, usw. Diese sind gut Dinge, aber sie sind von begrenztem Wert, weil sie das Wissen ausdrücken, das du zu dem Zeitpunkt über das System hast; Sie können dir nicht mit Dingen helfen, die du nicht kennst (gibt es einen hinterhältigen Fehler in meinem Algorithmus, den ich nicht kenne und an den ich nicht denken würde?).

Der wahre Wert von Unit Tests ist meiner Meinung nach der Wert, den sie im Laufe der Zeit gewinnen. Dieser Wert nimmt zwei Formen an; Dokumentationswert und Validierungswert.

Der Dokumentationswert ist der Wert des Komponententests, der besagt: "Dies ist der Code, den der Autor des Codes erwartet hat". Es ist schwer den Wert solcher Dinge zu übertreiben; Wenn Sie an einem Projekt mit einem großen, nicht dokumentierten Legacy-Code teilgenommen haben, lassen Sie mich Ihnen sagen, dass diese Art von Dokumentationswert wie ein Wunder wirkt.

Der andere Wert ist der der Validierung; Da der Code in Projekten weiterlebt, werden die Dinge umstrukturiert, verändert und verschoben. Komponententests bieten eine Validierung, dass die Komponente, von der Sie dachten, dass sie auf eine Art funktioniert, weiterhin auf diese Weise funktioniert. Dies kann bei der Fehlersuche in Projekten von unschätzbarem Wert sein. Zum Beispiel kann das Ändern einer Datenbanklösung manchmal durchsichtig sein, aber manchmal können diese Änderungen unerwartete Verschiebungen in der Art verursachen, wie einige Dinge funktionieren; Wenn Sie die Komponenten testen, die von Ihrem ORM abhängig sind, können Sie kritische geringfügige Änderungen im zugrunde liegenden Verhalten feststellen. Das wird wirklich nützlich, wenn Sie einen Teil des Codes haben, der jahrelang perfekt funktioniert, und niemand denkt daran, seine mögliche Rolle bei einem Fehler zu berücksichtigen. Diese Arten von Fehlern können SEHR lange brauchen, weil der letzte Ort, an dem Sie suchen werden, in der Komponente liegt, die für eine sehr lange Zeit felsenfest war. Unit Testing bietet die Validierung dieser "Rock Solidity".

Nein, Sie verpassen es nicht, das ist es, was Unit Testing Ihnen sagen soll. Sie haben die richtige Idee, indem Sie gute und schlechte Eingaben, Randfälle usw. testen. Sie benötigen für jede Bedingung einen Test. Ein Test wird alle Voraussetzungen festlegen und dann bestätigen, dass Ihre Berechnung (oder was auch immer) Ihren Erwartungen entspricht.

Ja, das ist es. Jede dieser Fragen, die Sie stellen, könnte als Test verwendet werden. Stellen Sie sich den Komponententest als drei Schritte vor. Richten Sie einige Voraussetzungen ein, führen Sie einen Code aus, der sich im Test befindet, und schreiben Sie eine Bestätigung, die Ihre Erwartungen dokumentiert.

In Ihrem Fall werden beim Einrichten von 'Sammlung' mit bestimmten Werten (oder keine Werte) die Vorbedingungen festgelegt.

Wenn Sie Ihre Suchmethode mit einem bestimmten Parameter aufrufen, wird der getestete Code ausgeführt.

Überprüfen Sie, ob der von Ihrer Methode zurückgegebene Wert mit dem erwarteten Wert übereinstimmt.

Geben Sie diesen drei Dingen einen Namen, der beschreibt, was Sie versuchen (DoesTheSearchMethodFailIfCollectionIsEmpty) und voila, Sie haben einen Komponententest.