Cucumber を使用すると、ユニットテストを書く必要がなくなりますか? 質問する

Cucumber を使用すると、ユニットテストを書く必要がなくなりますか? 質問する

Ruby/ROR で利用できるテスト フレームワークの数が多すぎて、少し混乱しています。

私は最近、Cucumber の Railscastそして、とても興味深いと思いました。それで、私は遊び始め、さまざまなテストを概念的にどこに置くべきかを考えるのに苦労しました。

Cucumber 内でユニット テストで実行できることはすべて実行できると思われますが、ユニット テストを記述する必要があるのでしょうか。それとも、機能定義を記述して、それを使用してできる限り優れたカバレッジを提供することに集中すればよいのでしょうか。

ユニットテストは Rspec または Test:Unit を使用して作成する必要がありますか? Ajax 機能をテストする場合は、Selenium または Watir を使用する必要がありますか?

ここには選択肢が多すぎるようで、どのツールを使うべきか、境界はどこにあるのかがわかりにくくなっています。

他の人の Cucumber の使用経験はどのようなもので、Cucumber 統合テストと Test:Unit および/または Rspec ベースのユニット テストと機能テストの記述の境界線はどこに引くべきでしょうか。テスト方法とさまざまなツールの長所と短所の境界線をどこに引くべきかについて、このテーマに関する優れた記事をご存知の方はいらっしゃいますか。

一部は主観的な部分もあるとは思いますが、この問題に取り組むための共通のアプローチがあれば歓迎します。

ベストアンサー1

Cucumberを使用して、ユーザーが見たり実行したりできる内容を高レベルで記述します。RSpec、Test:Unit、Shouldaなどを使用してユニットテストを記述します。馬の口:

新しい機能を追加したり、バグを修正したりすることに決めたら、まず、新しい機能や、その機能がどのように動作するかを説明するシナリオを記述します。まだコードは記述しないでください。

...

ここでコードを書き始めます。まず、Cucumber で発生したエラーに対処するために、数行のコードを記述します。もう一度 Cucumber を実行します。機能に満足するまで繰り返します。細かい詳細に取り掛かったら、抽象レベルを 1 つ下げて、RSpec または任意の Ruby テスト フレームワークを使用して、クラスの仕様/テストを記述します。

Cucumber は、「ユニット」ではなく、スタック全体をまとめてテストするように作られています。

どこで線を引くかを決める必要がありますが、多くの裏側はおそらく Cucumber テストではカバーされないでしょう。たとえば、サインアップ時に、名前、メール アドレス、電話番号などをフォームに入力します。ユニット テストでは、新しい によってUser新しい も作成されるかどうかをチェックする場合がありますTelephoneNumber。ユーザーの観点からすると、新しい が作成されることはあまり気にしませんTelephoneNumber。サインアップするとアカウントが作成され、電話番号を確認できることが重要なのです。

持っていないあまりにもキュウリのテストを書く経験はあまりありませんが(まだ)、これが少しでも役立つことを願っています。

おすすめ記事