Rspec で記述された 20k を超える単体テストを含むプロジェクトを調べ始めたところです (プロジェクト自体は Ruby で記述されておらず、テスト ケースのみです)。現在のテスト ケースの数は、機能が追加されるにつれて、将来的に劇的に増加すると予想されます。すでに (長期間にわたって) 起こったことは、RSpec がこのプロジェクトをテストするための特に優れたソリューションであるということです。彼らが抱えている最大の問題の 1 つは、テスト コードの分類法に関するものです。つまり、テスト ケース、フィクスチャ、ヘルパー コードなどに名前を付ける際の構造 (または欠如) です。
ご想像のとおり、20k を超える単体テストでは、非常によく似た名前のメソッドが多数あり、それらはすべてグローバル名前空間から読み込まれるヘルパー メソッドを使用しています。
問題が深刻な領域を 1 つだけ強調すると、このアプリケーション内には最大 10 個のデータベースがあります。これらすべてのデータベースについて、テーブル/列/ビュー/制約/ストアド プロシージャなどの構造をチェックすることは、既存の RSpec 単体テストで (かなり合理的に) カバーされています。ただし、チェックする必要があるこのデータベースのコレクション内の DDL エンティティの総数は、おそらく 10000 を超えています。DB 構造チェックの全範囲をカバーし、DB 構造のサブセットのみを選択的にテストできるようにするには、次のいずれかが必要です。
10000 の個別のメソッド (そして、私はそのオプションをすぐに除外します!)
- テスト ケース内のかなり複雑な命名規則 (つまり、DB 名 + テーブル名 + 列名 + ... を含むもの)、
- または、たとえば DB 名、テーブル名、列名などをジェネリック メソッドに渡します。
- または、名前空間による関心の分離 (RSpec 内でこれを行うエレガントでスケーラブルな方法を私は知りません)、
- または、いくつかの巧妙なメタプログラミング (最終的には、すでに厄介な構造を追跡するのがさらに難しくなる可能性があると思われます)。
現在存在しているのは、私が知る限り、上記のすべての一部であり、明らかな計画はあまりありません...
この混乱を正し、RSpec テストにある種のスケーラブルな構造を与えるために参照できるヒントや参考文献はありますか? 特に、非常に大規模なプロジェクト用にさまざまな RSpec ファイルを構成する方法についての提案は大歓迎です。