TDD /単体テストは初めてです。
Javaで複雑なスケジューリングアルゴリズムを記述します。このモジュールは私たちのアプリケーションのコア部分であり、そこには多くのシナリオがあるので、すべてのケースに対してユニットテストケースを書きたいと思います。
このスケジュールを計算するには、25〜30のエンティティとやり取りする必要があり、各エンティティには平均して10のフィールドがあります。
テストケースごとにこのような巨大なデータを構築すること(おそらく、基本的なエンティティデータの一部を再利用できるかもしれません)は、大変な作業のようです。
私の質問は、他の人はこの問題をどのように解決するのですか?
PS:依存関係を作成するため、データベースからデータを読み取ることは避けたいです。
単体テストケースのテストデータを作成するために推奨される方法は何ですか?
ホワイトボードを使用する
このスケジュールを計算するには、25〜30のエンティティとやり取りする必要があり、各エンティティには平均して10のフィールドがあります。
いいえ。ホワイトボードに戻る必要があります。
1つの有用なテストを作成するために250のフィールドを操作する必要はありません。問題を小さな部分に分解する必要があります。 250フィールドを使用するテストをなんとかして作成できたとしたら、私はそれを理解する望みがないので、確かにそれを信頼しません。
テストのポイントは、コードの読み取りを支援することです。脳が7つのことを同時に覚えることができれば幸運なので、問題を扱いやすい小さなチャンクに分解します。 250フィールドのテストを理解したいのなら、あなたは私に多くのことを覚えるように頼んでいるだけです。
これは、250のフィールドに関連する問題が発生しないということではありません。一度にすべてについて考えるように言わないでください。スケジューリングの問題は、通常、約3つのものです:期間、前提条件、およびリソース。詳細をプッシュして他の抽象化で処理するときは、問題のその単純なモデルを覚えておいてください。
それがデザインです。テストに必要なものを簡素化するために、設計を通過せずに問題にテストを投入することはできません。これを行うと、処理できることを証明したいケースを書き留めることができます。これがテストデータの出所です。
私の質問は、他の人がこの問題をどのように解決するのですか?
Javaでは通常、クラスパスからテストリソースを読み込むことでこれを行います。
私のプロジェクトのほとんどはMavenを使用しています。テストリソースはすべてsrc/test/resources
の下にあります。テストハーネス内で、Class::getResourceAsStream
から返されたInputStream
を介してデータにアクセスします。
これを行う必要があるほとんどの場合、サンプルファイルが既に利用できます(たとえば、プロダクションから保存されたデータ)。
ごくまれに、必要なデータを生成するプログラムを作成し、そのデータをリソースファイルに保存して、テストでロードします。
データが不変であることが想定されていて、データが大きく、特に人間が読めるものではない場合は、テストリソースをソースコードリポジトリにコミットするのではなく、テストリソースをjarに入れて、リポジトリにデプロイします。