BDD mit Gurke und rspec - wann ist das redundant?

Question

A Rails/Werkzeug bestimmte Version: How deep are your unit tests?

Im Moment schreibe ich zur Zeit:

• Gurke Funktionen (Integrationstests) - diese Prüfung gegen die HTML/JS, die von unserer App zurückgegeben wird, aber testet manchmal auch andere Dinge, wie Anrufe an Drittanbieter-Dienste.
• RSpec Controller Tests (Funktionstests), ursprünglich nur, wenn die Controller eine sinnvolle Logik haben, aber jetzt mehr und mehr.
• RSpec Modelltests (Unit-Tests)

Manchmal ist dies unbedingt erforderlich; Es ist erforderlich, das Verhalten im Modell zu testen, das für den Endbenutzer nicht vollständig offensichtlich oder sichtbar ist. Wenn Modelle komplex sind, sollten sie definitiv getestet werden. Aber zu anderen Zeiten scheinen mir die Tests überflüssig. Testen Sie zum Beispiel die Methode foo, wenn sie nur von bar aufgerufen wird und bar getestet wird? Was ist, wenn bar eine einfache Hilfsmethode für ein Modell ist, das in einer Cucumber-Funktion verwendet und leicht getestet werden kann? Testen Sie die Methode sowohl in rspec als auch in Gurke? Ich habe Probleme damit, da das Schreiben von mehr Tests Zeit kostet und mehrere "Versionen" der effektiv gleichen Verhaltensweisen beibehält, was die Wartung der Testsuite zeitintensiver macht, was wiederum die Änderungen verteuert.

Kurz gesagt, glauben Sie, dass es eine Zeit gibt, in der nur das Schreiben von Gurkenfunktionen ausreicht? Oder sollten Sie immer auf allen Ebenen testen? Wenn Sie denken, dass es eine Grauzone gibt, wie hoch ist Ihre Schwelle für "dies benötigt einen funktionalen/Einheitstest". In der Praxis, was machst du zur Zeit und warum (oder warum nicht) hältst du es für ausreichend?

---

EDIT: Here's an example of what might be "test overkill." Zugegeben, ich konnte dies ziemlich schnell schreiben, aber es war völlig hypothetisch.

Answer 1

Gute Frage, eine, mit der ich mich vor kurzem während der Arbeit an einer Rails App, die auch Gurke/RSpec verwendet, beschäftigt habe.Ich versuche auf jeder Ebene so viel wie möglich zu testen, aber ich habe auch festgestellt, dass ich mit der wachsenden Codebasis manchmal das Gefühl habe, dass ich mich unnötig wiederhole.

Mit "Outside-in" -Tests läuft mein Prozess normalerweise so ab: Gurkenszenario -> Controller Spec -> Model Spec. Mehr und mehr überspringe ich die Controller-Spezifikationen, da die Gurken-Szenarien einen Großteil ihrer Funktionalität abdecken. Ich gehe normalerweise zurück und füge die Controllerspezifikationen hinzu, aber es kann sich wie eine lästige Pflicht fühlen.

Ein Schritt, den ich regelmäßig mache, ist rcov auf meine Gurkenfunktionen mit rake cucumber:rcov laufen und nach bemerkenswerten Lücken in der Abdeckung suchen. Dies sind Bereiche des Codes, auf die ich mich konzentrieren muss, damit sie eine angemessene Abdeckung bieten, sei es Unit- oder Integrationstests.

Ich glaube, Modelle/Bibliotheken sollten sofort ausgiebig getestet werden, da es die Kerngeschäftslogik ist. Es muss isoliert arbeiten, außerhalb des normalen Web-Anfrage/Antwort-Prozesses. Wenn ich zum Beispiel über die Rails-Konsole mit meiner App interagiere, arbeite ich direkt mit der Geschäftslogik und möchte sicherstellen, dass Methoden, die ich an meinen Modellen/Klassen anrufe, gut getestet sind.

Am Ende des Tages, jede App ist anders und ich denke, es liegt an den Entwickler (s) zu bestimmen, wie viel Testabdeckung für verschiedene Teile der Codebasis gewidmet sein sollte und das richtige Gleichgewicht finden, so dass Ihr Test Die Suite lässt Sie nicht im Stich, wenn Ihre App wächst.

Hier ist ein interessanter Artikel, den ich von meinen Lesezeichen ausgegraben, die lesenswert ist: http://webmozarts.com/2010/03/15/why-not-to-want-100-code-coverage/

Answer 2

Ich teste komplexe Modell/lib-Methoden mit rspec dann die Hauptgeschäftslogik im Web mit Gurke, also bin ich mir sicher, dass die Hauptfunktionen des Webs 100% funktionieren, wenn ich mehr Zeit und Ressourcen habe, teste ich alles andere.

Answer 3

Rails hat eine gut getestete Codebase, daher würde ich es vermeiden, Dinge, die in diesen Schritten behandelt werden, erneut zu testen.

Zum Beispiel, wenn es sich nicht um benutzerdefinierten Code handelt, ist es sinnlos, die Ergebnisse der Validierungen auf Einheiten- und Funktionsebene zu testen. Ich würde sie jedoch auf der Integrationsebene testen. Gurken-Features dienen als Spezifikationen für Ihr Projekt. Daher ist es sinnvoll anzugeben, dass Sie eine Validierung für x und y benötigen, selbst wenn es sich bei der Implementierung um eine einzeilige Deklaration im Modell handelt.

Answer 4

Es ist einfacher, einfache Spezifikationen für einfache Methoden zu schreiben. Es ist viel einfacher als Cukes zu schreiben.

Wenn Sie Ihre Methoden einfach halten - und Ihre Spezifikationen einfach halten - indem Sie nur die Logik innerhalb dieser Methode testen, werden Sie Freude an Komponententests haben.

Wenn etwas überflüssig ist, testet seine Gurke. Wenn Sie gut getestete Modelle und Lib getestet haben, sollte Ihre Software funktionieren.

Answer 5

Sie in der Regel nicht wollen beide Gurke Geschichten und RSpec Controller specs/Integrationstests haben. Wählen Sie eine (in der Regel ist Gurke die bessere Wahl, außer für bestimmte Sonderfälle). Dann verwenden Sie RSpec für Ihre Modelle, und das ist alles was Sie brauchen.