POJOマンセーっていうけどさ
単体テストコードの生産性を第１に考えるとすると，フレームワークやアプリケーションコードに対してある程度余計な工数をかけてでも，フレームワークに依存していないアプリケーションコード（≒POJO）で書けるようにした方がトータルでハッピーではないかと。
テスト第一は全面的に同意。
POJOのメリットは、
- 特殊な環境に依存しないのでテストがしやすい。
- 余分なAPIをわざわざ覚える必要がない。
にあると思います。そもそも、POJOって何って話は､過去に何度もされていますが､特定のAPIに依存しないというより､「特定のクラスやインターフェースを継承したり実装する必要がない」くらいのほうが、現実的でしょう。今では､アノテーション使いまくりでもPOJOだといってますからね。
仮に特定のクラス(API)に依存したとしても､そのクラスがPOJO、あるいはインターフェースなら特に問題なく､テストのしやすいPOJOだといっても問題ないと思います。
特定のクラスを継承してもテストしやすければいいじゃんという意見もあるかもしれませんが､継承ベースでテストしやすくするには､かなり注意深い設計が必要です。それが可能なくらいの設計力があるなら､継承に頼らずに済ます方法を考えるのも十分にできるでしょう。
POJOとは、
- 特定のクラスやインターフェースの実装を前提としない。
- 依存しているクラスもPOJOもしくはインターフェース。
ということで良いのではないかと思います。それによりテストしやすいという最大のメリットを享受できます。
