バナナグラムのシミュレーションを書いています。現在、私はGameMasterピースの共通コレクションを維持するクラスを持っています。メソッドは、そのdeal(Player)プレーヤーに特定の数の駒を配ります。
このための単体テストを書きたいと思います。ただし、この時点ではゲッターがないため、オブジェクトのステータスを確認する方法がありません。
ゲッターを追加しないのはなぜですか? テストのためだけにパブリック インターフェイスにコードを追加したくありません。現時点では、これらの関数を公開する理由は他にありません。
ここで何をすればいいですか？とにかくゲッターを追加して、パブリック API を乱雑にしますか (または将来必要になることを期待しますか)? ユニットテストをやめますか？（悪い考えのように聞こえます。）
それとも、これは私のパブリック インターフェイスに欠陥があることを示していますか?
Player の具体的なインスタンスに依存する代わりに、単体テストをインターフェイス (または同等のもの) に記述し、モックまたはその他の相互作用に依存して、プレーヤーが正しい状態にあることを検証するのではなく、単に正しい呼び出し ( GameMaster クラスのビューから。
Player の最終状態の検証に依存せずに GameMaster クラスの正しい動作を検証できない場合、それは責任が見当違いであることを示しています。GameMaster は、何が起こったかを Player に伝える責任があり、Player は適切なアクションを実行する責任がある必要があります。
これは、GameMaster のテストが GameMaster クラスの動作のみに依存し、Player クラスがその動作を変更した場合に変更する必要がないことを意味するため、利点でもあります。
単体テスト用に getter を追加することは避けてください。getter を追加したくなったら、状態ベースのテストの代わりに (先ほど説明したように) 対話テストを使用することを検討してください。
コードの一部が機能することを確認する方法は複数あります。私たちのほとんどが最初に考えるのは、状態ベースのテストです (つまり、getter を使用して、オブジェクトの最終的な状態が想定どおりであることを検証します)。ただし、コードが機能することを確認する別の方法は、動作または相互作用ベースのテストを使用することです。
マーティン・ファウラーは、ここで違いについてまともな記事を持っています
単体テストはコードを改善するものではありません。変更や機能の追加により、アプリケーション全体の安定性を高めます。これが、GameMaster クラスに public getter がない場合、単体テスト用に作成する必要がない理由です。
ゲッターがいないからといって、インターフェイスがフローされているわけではありません。テスト駆動型開発の概念は、テストに合格するための最小限のコードを書くことです (これは要件に由来します)。print、trace、log は、単体テストが消えた後もずっとここに存在します (これらも残りますが、多くの場合、過剰に使用されすぎています)。
特にテスト容易性のためにコードを追加することに問題はないと思います。単体テストは、回帰テストにとって非常に貴重です。
ただし、パブリック API に影響を与えないことも正しいことです。したがって、ゲッターをパッケージで保護し、単体テストをPlayerクラスと同じパッケージに配置することをお勧めします。(ただし、運用コードとテスト コードを明確に分離するために、別のソース フォルダーにあります。)
これらの状態保持変数を内部的に使用している機能をテストする必要があります。公開されている機能がそれらを使用していない場合、それらはデッド コードです。
あなたのクラスはやりすぎかもしれません。状態を保存し、他のことをしているようです。
それらをテストしやすくするものを検討してください。状態とロジックを分離した場合、それらをどのようにテストしますか? ただ電話するのではなく
GameMaster gameMaster = new GameMaster;
playerOne.Score = gameMaster.ComputePlayerScore(newScore);
GameState の状態のみのインスタンスを GameMaster ルーチンのコンストラクターに渡します。
GameState gameState = new GameState;
GameMaster gameMaster = new GameMaster(gameState);
playerOne.Score = gameMaster.ComputePlayerScore(newScore);
その後、単体テスト ルーチンは、gameState と newScore に必要なデータを渡して、返された後に gameState で結果を確認できます。依存性注入はあなたの友達です。
できることの 1 つは、メイン クラスをサブクラス化して、テスト用のゲッターを提供することです。操作するインターフェイスがあれば、これはより簡単になります。
ゲッターを提供するためのサブクラス化は、やや危険な命題です。内部プロパティに getter を提供するだけであれば、被害は最小限に抑えられますが、派生バージョンではなく実際のクラスをテストしていることに注意する必要があります。
ここで何をすればいいですか？とにかくゲッターを追加して、パブリック API を乱雑にしますか (または将来必要になることを期待していますか)?
私はこの応答を取得しません。ゲッターはどのように「混乱」していますか?
あなたはテスト駆動開発を行っています。設計は、すべてをテストするという絶対的な必要性によって推進されています。
ゲッターは「乱雑」ではありません。それらは、物事をテストする方法です。
「ユニットテストをやめますか？」
これは良い考えではないと思います。