既存のシステムの改修という仕事がほとんどなわけで、残念ながらテストコードのない、レガシーコードだったりすることがほとんど。
なので、
レガシーコード改善ガイド (Object Oriented SELECTION)
を読みなおしているのだが、ここにあるテクニック、
jmockit - A developer testing toolkit for Java - Google Project Hostingを使うと、結構すんなり解決できるのでは?
jmockitの使用例って、ググってもそれほど見かけないような印象だけど、テスト対象のクラスの一部のメソッドをモックにできるので、
リファクタリングして多くのprivateなメソッドを呼び出しているような公開メソッドでも、変に悩まずに漏れのないテストパターンを用意できる。
テストコードの作成を嫌がる人は未だに多いため、テストコードの作成に手間取ると、変にバッシングされたり、コーディング能力を低く見られたりすることもある。だから、すんなりテストを書けるフレームワークを使いたいし、いろいろな使用例があれば、尚良い。
まぁ、そもそも未だにテストコードを否定するような職場にいるようであれば、レガシーなエンジニアになってしまわないよう、次の手を考える必要があるよね。