Ich habe einige Unit-Tests geschrieben, die einen Wrapper um eine FTP-Server-API testen.
Sowohl die Komponententests als auch der FTP-Server befinden sich auf demselben Computer.
Die Wrapper-API wird auf unserer Plattform bereitgestellt und sowohl in Remoting- als auch in Web-Service-Szenarien verwendet. Die Wrapper-API nimmt im Wesentlichen XML-Nachrichten, um Aufgaben wie das Hinzufügen / Löschen / Aktualisieren von Benutzern, das Ändern von Kennwörtern, das Ändern von Berechtigungen usw. auszuführen.
Wenn Sie in einem Komponententest einen Benutzer zu einer virtuellen Domäne hinzufügen, erstelle ich die XML-Nachricht, die an die API gesendet werden soll. Die API funktioniert und gibt eine Antwort mit Statusinformationen darüber aus, ob die Operation erfolgreich war oder fehlgeschlagen ist (Fehlercodes, Validierungsfehler usw.).
Um zu überprüfen, ob der API-Wrapper-Code wirklich das Richtige getan hat (falls die Antwort erfolgreich war), rufe ich die COM-API des FTP-Servers auf und frage direkt nach seinem Speicher, um beispielsweise beim Erstellen eines Benutzerkontos den Benutzer zu ermitteln Konto wurde wirklich erstellt.
Riecht das schlecht?
Update 1: @ Jeremy / Nick: Der Wrapper steht im Mittelpunkt des Tests, der FTP-Server und seine COM-API sind Produkte von Drittanbietern, vermutlich gut getestet und stabil. Die Wrapper-API muss die XML-Nachricht analysieren und anschließend die API des FTP-Servers aufrufen. Wie würde ich überprüfen, und dies kann ein dummer Fall sein, dass eine bestimmte Eigenschaft des Benutzerkontos vom Wrapper korrekt festgelegt ist. Zum Beispiel das Setzen der falschen Eigenschaft oder des falschen Attributs eines FTP-Accounts aufgrund eines Tippfehlers im Wrapper-Code. Ein gutes Beispiel hierfür sind die Geschwindigkeitsbegrenzungen für Upload und Download, die im Wrapper-Code umgesetzt werden können.
Update 2: danke allen für die Antworten. Den Leuten, die vorgeschlagen hatten, Mocks zu benutzen, war es mir in den Sinn gekommen, aber das Licht ist noch nicht eingeschaltet und ich kämpfe immer noch darum, meinen Wrapper mit einem Pseudo des FTP-Servers zu arbeiten . Wo befinden sich die Mocks und übergebe ich eine Instanz dieser Mocks an die Wrapper-API, die anstelle des Aufrufs der COM-API verwendet werden soll? Ich bin mir bewusst, dass ich spottete, aber darum kämpfte, mich darum zu kümmern, hauptsächlich weil ich finde, dass die meisten Beispiele und Tutorials so abstrakt sind und (ich schäme mich zu sagen) am Unbegreiflichen grenzt.
Sie scheinen Mischeinheit & amp; Komponentenprüfung Probleme.
Um zu überprüfen, ob der API-Wrapper-Code tatsächlich das Richtige getan hat (wenn die Antwort erfolgreich war), rufe ich die COM-API des FTP-Servers auf
Haltet genau dort. Sie sollten sich über den FTP-Server lustig machen und der Wrapper sollte gegen den Schein funktionieren.
Wenn Ihr Test sowohl den Wrapper als auch den FTP-Server ausführt, handelt es sich nicht um Unit Testing.
Um Ihren Wrapper mit einem Mock-Objekt zu testen, können Sie Folgendes tun:
UploadFile haben, können Sie blind ein Erfolgsergebnis zurückgeben und vielleicht den Dateinamen speichern, der in einem Array von Strings übergeben wurde. DownloadFile das interne String-Array überprüfen, um zu sehen, ob eine Datei mit diesem Namen bereits "hochgeladen" wurde. Der Pseudocode für einige Testfälle wäre:
%Vor%Ich hoffe, das hilft ...
Was testen Sie den Wrapper oder die API? Die API sollte so funktionieren, wie sie ist, also müssen Sie sie nicht testen, denke ich. Konzentriere deine Testbemühungen auf den Wrapper und tue so, als ob die API nicht existiere. Wenn ich eine Klasse schreibe, die Dateizugriffe durchführt, teste ich nicht den Build in Streamreader ... Ich konzentriere mich auf meinen Code.
Es hört sich nicht so an, als würden Sie fragen: "Soll ich die API testen?" - Sie fragen "Soll ich die API verwenden, um zu überprüfen, ob mein Wrapper das Richtige tut?"
Ich sage ja. Ihre Komponententests sollten bestätigen, dass Ihr Wrapper die von der API gemeldeten Informationen weitergibt. In dem Beispiel, das Sie beispielsweise angeben, weiß ich nicht, wie Sie die API nicht berühren würden. Also ich denke nicht, dass es schlecht riecht.
Ich kann mir nur vorstellen, wann es sinnvoll ist, in die API der unteren Ebene einzutauchen, um die Ergebnisse zu überprüfen, wenn die übergeordnete API schreibgeschützt ist. Wenn Sie beispielsweise einen Benutzer mithilfe der übergeordneten API erstellen können, sollte auch eine API auf hoher Ebene vorhanden sein, um auch die Benutzerkonten abzurufen. Benutze das.
Andere Leute haben vorgeschlagen, die untergeordnete API zu verspotten. Das ist gut, wenn du es kannst. Wenn die untergeordnete Komponente verspottet wird, sollten die Mocks überprüft werden, um sicherzustellen, dass der richtige Zustand eingestellt ist. OK.
Tags und Links unit-testing tdd