2

現在、私の開発プロセスは次のように流れています。

  1. WebRat を使用した統合テストとして期待される動作を説明します
  2. その動作を提供するためにRuby on Railsコードを書くので、テストに合格します
  3. リファクタリングして、プロセスの最後にテストが合格するようにします
  4. 次の統合テストを書きます

私の統合テストは、定義上、作成できるすべてのモデル、コントローラー、およびビューをテストしているように思えます。実際には、単体テストも書かないことで何かが足りないのでしょうか?

4

3 に答える 3

8

私は実際、ここであなたの視点にかなり同情しています. 私は CucumberとRSpec が大好きで、両方を使用していますが、常に同じコードを使用しているわけではありません。たとえば、最近は Rails コントローラーの RSpec の例を書くことはめったにありませんし、ビュー スペックを書くこともほとんどありません。私のコントローラーのほとんどは非常によく似ており、Rails 独自の単体テストで既に十分にテストされている「ストック」コントローラー パターンから大きく逸脱していません。同じ動作を再度検証しても、時間がかかり、すべてのモデルをモックする手間がかかります。統合レベルの Cucumber を使用すると、そのモックをスキップして、探している重要な検証を取得できます。ほとんどの場合、ビューのテストも Cucumber ではるかに透過的に処理されます。(その後、「foo」が表示されるはずです

しかし、私が Rails で RSpec を広範に使用していないと言っているわけではありません。モデル、コントローラー フィルター、ビュー ヘルパーなど、ロジックが存在する場所に使用します。また、複雑なサードパーティ インターフェイスに対するライブラリや API アダプタなど、ほぼすべてがビジネス ロジックであるプロジェクトもいくつかあります。それらの場合、私は通常、RSpec のみを使用し、Cucumber をスキップしていることに気づきます。

ヒューリスティックとして、次の質問のいずれかに「はい」と答えられる場合はいつでも、単体テストを作成することを強く検討することをお勧めします。

  • 私が書いているコードは、それほど複雑ではありませんか?
  • このコードは、主に他のコードへの回答を提供するために存在しますか?
  • 私がリファクタリングしているこの既存のコードはありますか (単体テストはまだありません)?
  • このコードでバグを見つけましたか? (もしそうなら、それを修正する前に単体テストを書いて、二度と侵入しないようにしてください。)
  • このコードを実装する最も洗練された方法について、10 秒以上考える必要がありますか?
  • 私のSpidey Senseはチクチクしていますか?

上記のいずれにも当てはまらない場合は、統合テストを行うだけで済む可能性があります。繰り返しますが、それが妥当な場合はたくさんあります。ただし、後で問題が発生した場合は、代償を支払う準備をしてください。その代償には、必要と思われる場合にいつでも単体テストを作成することが含まれている必要があります。

于 2009-10-20T02:29:19.567 に答える
3

統合テストは、コードのさまざまな部分が適切に統合されていることを確認するのに役立ちます。それらはすべてのレイヤーを含み、すべてのコードをカバーするかもしれませんが...統合テストが失敗した場合、バグがどこにあるかがわかりますか? 私は間違っているかもしれませんが、そうは思いません。これは、どこかに問題があることを示しているだけです。一方、実際の単体テスト (モックまたはスタブを使用して個別に記述) が失敗した場合、問題がどのユニットにあるかが正確にわかります (これが実際の単体テストの目的であり、ユニットが期待される動作を実装していることを確認します)。 . つまり、単体テストと統合テストはどちらも便利ですが、目的が異なります。

于 2009-10-14T00:58:16.247 に答える
2

レーキのタスクはありますか? カスタム カピストラーノ コード? Cronメソッド？API？モンキーパッチ？flex または iPhone アプリの統合はどうですか? ジョブランナー？

典型的な Rails アプリケーションには、HTML UI によって実行されないコードがたくさんあります。いいえ、アプリが信じられないほど単純でない限り、webrat テストは十分ではありません。

于 2009-10-13T23:03:11.117 に答える