模拟抽象类一开始似乎很吸引人，但是抽象类的构造函数中的一些更改可能会破坏使用抽象类模拟的单元测试。所以单元测试隔离不是100%。我的意思是没有人能保证抽象类的构造函数是简单的。（我的意思是不要抛出，不要调用 DB 或类似的奇怪东西）。我知道构造函数应该很简单，但我不能保证它会一直保持简单。
我们遗留的代码库很重抽象类，我不太喜欢模拟抽象类。这是我更喜欢接口或抽象类的包装接口的主要原因。有没有办法围绕基类构造函数的调用？老实说，我从未在 TDD 期间创建过抽象类，但我无法更改系统的遗留部分。
我偏向于接口，但我想知道我提到的问题是真实的，还是可以绕过的。
I would use interfaces over abstract classes as unless there's a good argument against it composition is preferable than inheritance.
But are you using a code productivity tool such as ReSharper or CodeRush? They allow you to refactor code including constructors efficiently which will save you hours in instances such as this.
我认为你提到的问题是绝对真实的。在测试中模拟一个抽象类并使用它的构造函数或它的具体方法之一实际上相当于测试被测类和抽象类。它不再是真正的单元测试。模拟已经是脆弱的动物，这只会给他们一个额外的理由来搞砸你的测试。
我想解决方案几乎包含在您的问题中 - 使用接口。最好让遗留抽象类直接实现这些接口，但也可以包装它们并依赖包装器的接口而不是抽象类。
在依赖关系方面，“界面偏见”可能不是一个坏主意。接口定义了一个契约，描述了协作者上可用的操作。抽象类（不是纯粹的抽象类，与接口相比毫无用处）描述了一系列类在执行特定操作时的行为方式。您不想依赖于如何与细节耦合，您希望与高级抽象耦合。
正如 neoistheone 评论的那样，您可以使用 Microsoft Fakes框架从抽象类生成存根。