2016-04-18 3 views
-2

Recenly verbrachte ich einige Zeit mit dem Schreiben von Komponententests für meine Anwendungen. Nach einer Weile habe ich in meinem Code ein Muster gefunden, das mir eigentlich nicht gefällt.Unit-Test-Funktionen ohne offensichtliche Ausgabe oder Datenänderungen

Im Moment bin ich mit Unit-Test-Namensschema von „ifThisThanThat“, aber zu viele meiner Tests endete mit so etwas wie: „ifPassWrongDataThenNoError“, und ich habe zu viele dieser „ThenNoError“ Dinge.

Auf der einen Seite möchte ich alle verdächtigen Fälle mit den falschen Daten testen und etwas auf seltsame Weise aufrufen, aber auf der anderen Seite ändern alle diese Anrufe nichts außerhalb und geben keine Nebeninformationen abgesehen von den Fehlern im Falle etwas schief gelaufen ist.

Manchmal könnte es das Gegenteil sein, "... ThenThrowsError", aber immer noch, ich bin mir nicht sicher, dass es das richtige Design ist. Manchmal könnte es Methoden sein, die mit der Benutzeroberfläche oder mit den Daten kommunizieren, die in den Objekten eingeschlossen sind, und die, die ich nicht mit der Getter-ähnlichen Funktion öffnen möchte.

Ich bin nur wirklich Curiouse sollte ich und wie sollte ich diese Tests ändern, damit sie aussehen und fühlen mehr ... traditionell? Sind sie gut oder schlecht? Wie, ernsthaft, ich fühle mich nicht richtig, wenn ich keine Assert-Prüfung in der ganzen Einheit Testfunktion verwende, ich überprüfe nur, dass alles gut geht.

UI Beispiel: wir fügen ein Element zur Liste hinzu und es zeichnet sich auf der Bühne, ich überprüfe, dass die Funktion keinen Fehler erzeugt, wenn wir darum bitten, ein NULL/falsches Element hinzuzufügen. Es gibt keine Möglichkeit, die Liste vom Objekt abzurufen, da es keinen Grund gibt, es jemandem zu geben, es akzeptiert einfach ein neues Element und zeichnet es mit anderen.

+0

Ihre Frage ist zu allgemein, Sie müssen versuchen, genauer zu sein. Auf den ersten Blick scheint es, als wäre das Problem, dass der Code, den Sie schreiben, nicht besonders testfreundlich ist, anstatt ein Problem mit Ihren tatsächlichen Tests. Es scheint so, als müssten Ihre Tests * auf die Liste zugreifen oder * könnten * überprüfen, dass die Benutzeroberfläche aktualisiert wurde, um die neuen Informationen zu berücksichtigen. – forsvarir

+0

Ok, hab es, danke. Das ist also ein Konstruktionsfehler. –

Antwort

0

Ok, anscheinend gibt es in den meisten Fällen eine Möglichkeit, irgendeine Art von Feedback zu bekommen, in anderen Fällen kann ich Informationen zumindest ein wenig speziell für die Tests öffnen.

Im Beispiel der Benutzeroberfläche kann ich ein Ereignis verwenden, das vom Rendern einer neuen Liste stammt, oder auf das Zeitlimit warten, wenn das Renderereignis nicht abgerufen wird, falls nichts überprüft wurde. All dies fügt der Ausführung der Tests mehr Zeit hinzu.

Um Timeouts zu vermeiden, werde ich das Objekt anzeigen und direkt überprüfen, ob die Render-/Validierungsfunktion aufgerufen wurde oder nicht.

Verwandte Themen