問題タブ [shoulda]

新しいRailsプロジェクトでスペックまたはジェネレーターを実行しようとすると、subjでエラーが発生します。

これは、shouldaをミックスに追加したときに発生します。

config/environment.rbに以下を追加しました。

私はOSXを使用しています。

• ルビー1.8.6（2008-08-11パッチレベル287）
• 宝石1.3.5
• レール2.3.4
• rspec-1.2.6
• shoulda-2.10.2
• テストユニット-2.0.3

私はこれを認識しており、追加config.gem 'test-unit', :lib => 'test/unit'すると例外がスローされないため、ジェネレーターの問題は実際に解決されますが0 tests, 0 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications、実行の最後に出力されるため、予期しない望ましくないテストを実行しようとしていると思います。また、仕様は停止します。まったく実行しますが、rspecがまったく実行されていないようです。実行するrake specと、テストユニットの出力が再び表示されます（仕様のみでテストが定義されていないため、テストは0です）。

Railsアプリケーション用の一連のTest::Unitテストがあります。これは、Ruby 1.8.6、Rails2.3.4のOSXで開発されました。

私はthoughtbot-shoulda2.10.2も使用しています。

工場ではなく、標準のRailsフィクスチャを使用しています。

別の開発者が作業できるように、プロジェクトをCentOSLinux5ワークステーションにチェックアウトしました。彼はRuby1.8.7を実行しています。

（アプリは本番環境のCentOS Linux 5で実行されており、そこでは正常に動作しています。）

私の同僚のCentOS開発マシンでは、すべての単体テストに合格しています。

ただし、すべてではありませんが、ほとんどの機能テストでエラーが発生しています。トラブルシューティングの範囲を絞り込むために、1つのテストを分離しました（プロジェクトから他のすべてを削除しました）。

私たちが得ているエラーは...

重要な謎は、なぜAddressそのIDでを見つけることができないのかということだと思います。

もう1つの要因は、このブロックをコメントアウトすると、残りのテストに合格することです。

これを見た人はいますか？

トラブルシューティングの提案？

Rubyコミュニティで利用できる多くのテストフレームワーク、つまりunittest、 rspec、shoulda、couldaを使用して、Railsモデルをテストするための最も適切なテストフレームワークは何でしょうか。

それらは基本的に同じ機能を持っていますか？それは私のモデルをユニットテストすることです？いつどちらを使うべきですか？一方を使用し、もう一方を使用しないことの利点は何ですか？私が決めるのを手伝ってください。

洞察をありがとうございました。

新しいアプリケーションの場合、BDDで手を出し始めたいのですが、RSpecを使用するかThoughtbotのShouldaを使用するかを決定しようとしています。私はShouldaが使用するマクロが好きで、Ruby / Railsがテストを行う方法を再発明しているようには見えないが、単にアドオンを提供しているという事実が好きです。一方、マクロは、テスト対象を明示するのではなく、少し「魔法」のように見えます（ただし、「xxxがないと無効になるはずです」という2つのライナーを1ダース書くのは面倒だと私は知っています。モデル）。正直なところ、モデルの仕様やテストを書くのは簡単で退屈なほど簡単ですが、何をテストするのか、どのように書くのかが正確にわからないため、コントローラーの仕様やテストを書くのはめちゃくちゃ難しいと思います。

モックとスタブは誤った仮定を与えると思うので（必要なデータがあると思うか、メソッドXが呼び出されたふりをするように指示できるため）、RSpecが重くなることを知っています。それらの両方の使用。私はRSPecが作成するドキュメントが好きですが、クライアントに提供するのではなく、販売用のアプリケーションを作成しているので、きれいなドキュメントはそれほど役に立ちません。私はキュウリが好きですが、それはやり過ぎのようです（そして、はい、それはShouldaで使用できることを知っています）。

この時点で、RailsコミュニティはRSpecまたはShouldaを支持していますか？

通常、メソッド「delete_user_test」の次のコマンドライン構文を使用して、通常の Test::Unit メソッドをテストできます。

Test::Unit で shoulda プラグインを使用しているときは、次のように同じ手法を使用しようとしています。

次に、次のように単一のテストを実行しようとします。

これはうまくいきません。shoulda と Test::Unit を使用してシングル コンテキスト テストを実行する方法を知っている人はいますか。1 つのテスト ファイルにいくつかの異なるテストがあり、すべてのテストが実行されるのを待つことなく、TDD を使用して 1 つだけを実行したいと考えています。

私はShoulda + FactoryGirlテストをスピードアップする方法を探しています。

テストしようとしているモデル（StudentExam）には、他のモデルとの関連付けがあります。これらの関連オブジェクトは、を作成する前に存在している必要がありますStudentExam。そのため、で作成されsetupます。

ただし、モデルの1つ（School）の作成にはかなりの時間がかかります。setupすべてのステートメントの前に呼び出されるためshould、テストケース全体の実行には何年もかかります。つまり、実行されるすべてのshouldステートメントに対して新しい、、が作成されます@school。@student@topic@exam

これらのオブジェクトを一度だけ作成する方法を探しています。テストケースの残りの部分を通して持続するレコードを作成できるstartupforメソッドのようなものはありますか？before_all

基本的に私はRSpecのbefore（：all）とまったく同じものを探しています。これらのテストではこれらの高価なオブジェクトが変更されることはないため、依存関係の問題については心配していません。

これがテストケースの例です。長いコードについてお詫びします（私も要点を作成しました）：

コントローラーの例でモデルをモックアップしているため、カバレッジに穴が開いています。コントローラが依存しているモデルのメソッドを削除しても、失敗は発生しません。

静的に型付けされた言語のTDDから来て、私は常に、速度を上げるためにデータベースにヒットするテスト対象のオブジェクトへの依存関係を模倣していました。上記の例では、モックが元のオブジェクトをサブクラス化したため、引き続き失敗します。動的言語でのベストプラクティスを探しています。

ありがとう。

アップデート：

これについて多くの相反する意見を得た後、それはあなたがどの哲学に賛成するかに要約されるようです。

Rspecコミュニティは、テスト対象のオブジェクトの分離を実現するために、依存関係を大幅にスタブ化するように見えます。受け入れテスト（従来は統合テストと呼ばれていました;）は、オブジェクトが実行時の依存関係で機能することを確認するために使用されます。

shoulda / Test :: Unitコミュニティは、可能な限りスタブを避けているようです。これにより、テスト対象のオブジェクトが実際にその依存関係で機能することをテストで確認できます。

このビデオはこれをうまく要約しています：http：//vimeo.com/3296561

Railsアプリで新しいモデルを作成しました。これは別のテーブルとの1対1の関係であるため、新しいモデルにid列を含める必要はありません。すべてが正常に機能していますが、何らかの理由で、このモデルでの私のShouldaテストはすべて失敗しています。例えば：

このエラーをスローしています：

ID列が必要ですか？もしそうなら、これを回避する方法はありますか？

私が取り組んでいるプロジェクトの 1 つで、Test::Unit と組み合わせて Shoulda を使用しています。私が直面している問題は、最近これを変更したことです。

これに：

以前、私の（合格した）テストは次のようになりました。

私が知る限り、should_validate_presence_of上記の変更でこのテストをパスし続けるパラメータはありません。の要件をテストするときに Shoulda を放棄する以外に、:attribute_twoこれを回避する方法はありますか?

「Project」というモデルの下にネストされたリソースである「Post」というモデルがあり、コントローラーをテストしようとしています。コードはブラウザで動作しますが、テストでは動作しません。これがテストです

私がこれをどのように台無しにしているのか分かりますか？