ActiveRecord::Base から継承するクラスが与えられた場合、それを Task と呼びましょう。標準の Rails 単一テーブル継承を使用して、Activity と Training というタスクのいくつかの側面を特殊化する 2 つのサブクラスがあります。
モデルの実際のデータは同じであるため、他の利用可能なものを見て、その選択に自信があります。異なるのは動作だけです。STIにぴったり。
タスクは、作成、開始、進行、および終了できます。start()これは、基本クラスの特殊化を必要とする、これらの遷移、特に に関連するロジックです。
私はこの TDD を行っており、完全なテスト カバレッジを備えた動作中の Task 呼び出しから始めたので、どのように進めればよいのか疑問に思っています。私が考えたいくつかのシナリオがあります：
Task のテストを複製し、Activity と Training の両方をエンド ツー エンドでテストし、専門性をテストするためにいくつかの小さな変更を加えます。長所: 迅速かつ簡単です。短所: コードが重複します。ここでは大きな問題ではないかもしれませんが、特殊化の数が増えると問題が発生します。
テストを分割し、ほとんどのテスト コードを保持し
task_spec.rbながら、特殊化テストをそれぞれのサブクラスの新しい仕様に移行します。長所: テストを DRY に保ちます。短所: 基本テストでどのクラスをインスタンス化しますか?
その最後の質問は、私を悩ませているものです。現在、concert サブクラスの 1 つからランダムにクラスを作成するように基本クラスのテストをセットアップしていますが、これは適切な形式でしょうか? テスト実行の一貫性を保つためだけにアプローチ 1 を使用したいと思うようになるか、テスト スイートのランダム シードのクラス選択のランダム性に基づく方法を見つけて、少なくとも再現性のある方法を見つける必要があります。ランダム選択。
これは人々が遭遇する一般的な問題であるに違いないと思いますが、この件に関する良い情報は見つかりません. この問題について何かリソースや考えはありますか?