如何使用DUnit测试单例类？

Question

或者使用另一种设计模式更好？

Answer 1

几天前，here, mocking a Singleton回答了一个类似的问题。最初的帖子是针对C#.Net关于模仿单例的行为的，但仍然应该适用。

至于单例模式，它本身没有任何问题-在许多情况下，我们希望集中逻辑和数据。然而，单例类和静态类之间有很大的区别。将单例构建为一个静态类，对应用程序中的每个使用者硬编码实现--这使得单元测试非常困难！

您要做的是为您的单例定义一个接口，公开供您的消费者使用的方法。反过来，你的消费者被传递给一个实例化实现类的引用，通常这是你的应用程序，或者是一个容器，如果你熟悉依赖注入\控制反转。

就是这个框架，不管是谁实例化消费者，都要负责确保一个且只有一个实例在浮动。从静态类到接口引用的飞跃真的不是很大，正如上面的链接所展示的那样，你只是失去了全局可访问实例的便利性-我知道我知道，全局引用非常诱人，但Luke把他的背影转向了黑暗面，你也可以！

一般来说，最佳实践建议避免静态引用，并鼓励针对接口进行编程。请记住，仍然可以应用具有这些约束的单例模式。遵循这些指导原则，您应该可以对您的工作进行单元测试:)

希望这能有所帮助！

singleton !=公共静态类，而不是singleton ==单实例

Answer 2

缺乏可测试性是经典单例模型(返回实例的静态类方法)的主要缺陷之一。就我而言，这足以重新设计任何使用单例来使用其他设计的代码。

如果你绝对需要一个单一的实例，那么依赖注入和编写接口，就像johnny g建议的那样，绝对是可行的。

Answer 3

I'm using the following pattern当我写一个基于静态的单例时，我可以模拟。代码是Java，但我想您会有所了解的。这种方法的主要问题是，您必须将构造函数放松为包保护(这在某种程度上击败了真正的单例)。作为附注-代码适用于模拟“静态”代码的能力，而不是简单地调用它