受け取ったパラメータに基づいてオブジェクトを作成するファクトリクラスがあります。パラメータは、作成するオブジェクトを指定する識別子です。その最初のステップは、データアクセス層を使用してオブジェクトの情報を取得することです。その次のステップは、データに対していくつかのクレンジング/変換を行うことです。最後に、必要なオブジェクトを作成して返します。
クレンジング/変換ステップが正常に行われたことを確認したいのですが、返されるオブジェクトは状態を公開しないため、簡単にテストする方法がわかりません。
データアクセス層とデータベース構造は、レガシーコードで動作する必要があるため、変更できません。
オブジェクトが使用された後、システムでさらにテストすることはできますが、それは維持するのが難しい大きなテストにつながります。
オブジェクトの状態を公開したり、責任を別のクラスに入れてテストしたりすることも考えましたが、どちらのオプションも、テスト用にシステムを変更しているようです。
このようなものをテストする他の方法について何か考えはありますか？
ユニットテスト内でテストしすぎているように思えます。
これは、ユニットがやりすぎを試みていることの症状です。
ここで3つのことをしようとしています。
修正するために、あなたが提案したように、私はこれらの責任のそれぞれを独自のユニット（クラス/メソッド）に移動します。次に、各ユニットを独自にテストできます。
テスト用にシステムを変更したくないので、これを行うことを躊躇します。ただし、単体テストの利点は、設計の欠陥を明らかにすることです。テスト用にシステムを変更するだけでなく、システムを改善し、よりきめ細かくして、保守性と再利用性を高めています。
あなたのファクトリオブジェクトはここでやりすぎを試みています。コードをリファクタリングして、データを別のオブジェクトにクレンジングし、そのオブジェクトの動作をテストする責任を与えることをお勧めします。
オブジェクトの状態を公開したり、責任を別のクラスに入れてテストしたりすることも考えましたが、どちらのオプションも、テスト用にシステムを変更しているようです。
そうです、あなたはテストのためにシステムを変更しています。そしてそれは良いことです。これは、クラスに責任を少なくするという道を強制することによって、より緩い結合とより高い凝集度を示すより良い設計を推進するテスト駆動設計の例です。（理想的には、各クラスの責任は1つだけです。）これはTDDの重要な利点の1つなので、戦わないでください。
私はこれを達成するための2つの方法を知っています：-Javaで、リフレクションを使用することによって。-（そして最高のIMO）プログラミングはインターフェースに焦点を合わせているので、データにアクセスできるインターフェースを実装できます。