似乎有三种通用模式可用于测试派生类与其基1 交互的方式。我真的不喜欢他们中的任何一个，原因我在下面列出。有没有人使用其中一种(或另一种)方法测试基类交互取得了长期成功？
- Change the access modifiers允许
Friend(C# 中的internal)访问并设置InternalsVisibleTo以包含模拟框架/单元测试程序集
更改 SUT 以允许测试是一种测试气味。如果该方法是 Protected，它就是 Protected，因为这是适合它的设计(实际上我还没有看到我所说的 Protected 的“有效”使用 friend (protected internal))。
- Use reflection and an extension method创建一个你想模拟的方法的可访问版本......然后模拟它
这需要大量额外的工作来模拟单个方法，它不是完全类型安全的(例如重命名会杀死它)，并且(至少在 VB 中)需要创建一个 Module将方法放入，这是一个设计噩梦(模块不能进入类内部，因此它们最多需要成为 Friend，而你的泛型更复杂)!
- 使用状态测试而不是行为测试。
根据基类的复杂程度，对于同一事物，这可能需要很多 比单个行为测试更多的测试。考虑在状态测试中需要什么来匹配 Me.AssertWasCalled(Function(s) s.SendMessage(messageText, [to]))，其中 SendMessage 是一个基类 protected 方法。
1注意:在支持通过方法的 String 名称模拟 protected 方法的 Moq 中，这不是必需的。正如 Ayende 在上面的链接中提到的，他特别避免了 Rhino Mocks 中的任何非编译时类型安全模拟(我认为这是一件好事!)
最佳答案
只是我的拙见。
一般来说，测试与基类的交互并不是一个好主意。因为您要在此处测试实现细节。
如果将继承类与基类一起测试似乎很复杂，那么可能是时候重构并使用聚合而不是继承了？
关于.net - 单元测试与基类交互的方法，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13845331/