派生クラスがその base 1と対話する方法をテストするには、3 つの一般的なパターンがあるようです。以下にリストした理由により、私はそれらのどれもあまり好きではありません。基本クラスの相互作用をテストするために、これらの (または別の) メソッドのいずれかで長期的に成功した人はいますか?
- アクセス修飾子を変更して
Friend
(internal
C# で) アクセスを許可InternalsVisibleTo
し、モッキング フレームワーク / 単体テスト アセンブリを含めるように設定します。
テストを可能にするために SUT を変更することは、テストの匂いです。メソッドが である場合はProtected
、それが適切な設計であるためです (実際には、 ( )Protected
の「有効な」使用法と呼ぶものをまだ確認していません)。Protected Friend
protected internal
- リフレクションと拡張メソッドを使用して、モックしたいメソッドのアクセス可能なバージョンを作成してから、モックします
これは、単一のメソッドをモックするために多くの余分な作業を必要とし、完全に型安全ではありません (たとえば、名前を変更するとそれが殺されます)。(少なくとも VB では)、Module
メソッドを配置するための を作成する必要があります。悪夢です (モジュールはクラス内に入れることができないためFriend
、最大限に制限する必要があり、ジェネリックはより複雑になります)!
- 動作テストの代わりに状態テストを使用します。
基本クラスの複雑さによっては、同じことに対して単一の動作テストよりも多くのテストが必要になる場合があります。Me.AssertWasCalled(Function(s) s.SendMessage(messageText, [to]))
where SendMessage
is a base class Protected
methodに一致する状態テストで何が必要になるかを考えてみましょう。
1String
注: これは、メソッドの名前による保護されたメソッドのモックをサポートする Moq では必要ありません。上記のリンクで Ayende が言及しているように、彼は Rhino Mocks での非コンパイル時のタイプ セーフなモッキングを具体的に回避しました (これは良いことだと思います!)。