RSpec vs Gurke (RSpec stories)

Question

Wann sollte ich Spezifikationen für Rails-Anwendung und wann Gurke (früher rspec-Geschichten) verwenden? Ich weiß natürlich, wie beide arbeiten und Spezifikationen aktiv nutzen. Aber es fühlt sich immer noch komisch an, Gurke zu benutzen. Meine aktuelle Ansicht ist, dass es praktisch ist, Cucumber zu verwenden, wenn Sie eine Anwendung für den Client implementieren und nicht verstehen, wie das ganze System noch funktionieren soll.

Aber was ist, wenn ich mein eigenes Projekt mache? Die meiste Zeit weiß ich, wie die Teile des Systems interagieren. Alles, was ich tun muss, ist eine Reihe von Komponententests zu schreiben. Was sind die möglichen Situationen, in denen ich Gurke dann brauchen würde?

Und als eine entsprechende zweite Frage: Muss ich Spezifikationen schreiben, wenn ich Gurkengeschichten schreibe? Wäre es nicht doppelt getestet?

Answer 1

Wenn Sie es nicht schon getan haben, sollten Sie Dan North's ausgezeichneten Artikel, What's in a Story? als Ausgangspunkt betrachten.

Wir haben zwei Hauptanwendungen für Gurken Geschichten. Erstens, weil die Story-Form sehr spezifisch ist, hilft es, die Artikulation der Merkmale des Produktbesitzers, die er bauen will, zu fokussieren. Dies ist der "Token für eine Konversation" der Verwendung von Stories und wäre wertvoll, unabhängig davon, ob wir die Stories im Code implementiert haben oder nicht. Zweitens, wenn der Prozess gut genug funktioniert, dass wir komplette Geschichten haben vor wir beginnen, die Funktion zu schreiben (mehr von einem Ideal, das wir anstreben als eine tägliche Realität), haben Sie Ihre Akzeptanzkriterien klar formuliert und Sie wissen genau was und wie viel zu bauen.

In unserer Rails-Arbeit ersetzen Cucumber-Stories keine Rspec-Unit-Tests. Die beiden gehen Hand in Hand. In der Praxis neigen die Komponententests dazu, die Entwicklung der Modelle und Controller voranzutreiben, und die Geschichten neigen dazu, die Entwicklung der Ansichten voranzutreiben (wir neigen nicht dazu, rspec für unsere Ansichten zu schreiben) und bieten einen guten Test der gesamten Anwendung von Benutzerperspektive.

Wenn Sie alleine arbeiten, ist der Kommunikationsaspekt möglicherweise nicht so interessant für Sie, aber die Integrationstests, die Sie von Cucumber erhalten, könnten sein. Wenn Sie die Vorteile von webrat nutzen, kann das Schreiben von Gurken für viele Ihrer grundlegenden Funktionen schnell und schmerzlos sein.

Answer 2

Eine Gurkenstory ist eher eine Beschreibung des Gesamtproblems, das Ihre Anwendung löst, als wenn einzelne Codebits funktionieren (z. B. Komponententests).

Wie Abie beschreibt, ist es fast eine Liste von Anforderungen, die die Anwendung erfüllen sollte, und ist sehr hilfreich für die Kommunikation mit Ihrem Kunden, sowie direkt testbar.

Answer 3

Betrachten Sie es als Zyklus:

Schreiben Sie Gurke Feature, dann, während die Stücke für diese Funktion zu entwickeln, Spezifikationen schreiben die einzelnen Komponenten zu vervollständigen. Fahren Sie mit dem Ausfüllen der technischen Daten fort, bis Sie genügend Funktionen für die Übergabe der Funktion geschrieben haben, und schreiben Sie Ihre nächste Funktion.

Answer 4

Aber was ist, wenn ich mein eigenes Projekt mache? Die meiste Zeit weiß ich, wie die Teile des Systems interagieren. Alles, was ich tun muss, ist eine Reihe von Komponententests zu schreiben. Was sind die möglichen Situationen, in denen ich Gurke dann brauchen würde?

Sie brauchen immer noch Gurke. Sie benötigen es, um zu dokumentieren, wie das System funktioniert, und Sie benötigen es, um sicherzustellen, dass Sie die Funktionalität nicht beim Ändern der Dinge unterbrochen haben.

Mit anderen Worten, Sie brauchen Gurken Geschichten aus den gleichen Gründen wie Sie Unit Tests benötigen - sie arbeiten nur auf einer höheren Abstraktionsebene.

Answer 5

Heutzutage können Sie rspec mit Capybara und Selenium Webdriver verwenden und müssen nicht alle Cucumber-Story-Parser erstellen und pflegen. Hier ist, was ich empfehlen würde:

1. Schreiben Sie Ihre Geschichte
2. Mit RSpec, würde ich einen Integrationstest ex erstellen: spec/Integrationen/socks_rspec.rb
3. Dann würde ich einen Integrationstest schaffen, die umfasst eine neue beschreiben und es für jedes Szenario blockieren
4. Dann würde ich implementieren die minimale Funktionalität erforderlich, um den Integrationstest zu erhalten und während tiefer (in Controller und Modelle, etc) Ich würde TDD auf Controller und Modelle.
5. Wie Sie zurückkommen sollen Sie Ihren Integrationstest bestehen und Sie können weiterhin Schritte zum Integrationstest

Eine Sache zu beachten,

Wiederholung jedoch hinzuzufügen ist, dass die Steuerung und Integrationstests Überlappung das ist vielleicht nicht notwendig, also müssen Sie Ihr bestes Urteilsvermögen verwenden, damit Sie keine Zeit verschwenden.

Auch wenn Sie Ihren Groove finden Sie es am angenehmsten zu entwickeln mit BDD, bis dann nicht schuldig fühlen, wenn Sie nicht das Gefühl haben, Sie tun es perfekt und nicht darüber nachdenken. Du wirst das sehr gut machen!

Answer 6

Ich nehme an, dass es eine schlechte Idee ist, Gurke in den meisten Situationen wegen der Kosten in der Produktivität zu verwenden, die ihre Syntax auf Sie verursacht. Ich schrieb ausführlich über das Thema in Why Bother With Cucumber Tests?