Question

我有一个嘲弄的问题。我知道只有公共方法才应该被嘲笑。但是，当在公共方法中调用私有方法时，我该怎么做，而这个私有方法是从文件中获取数据？我想模仿这个私有方法，所以我可以继续测试公共方法。

我可以公开让测试工作，但这是没有意义的，因为它是私有的。我也可以将所有内容移动到另一个类中并在那里公开函数，但是对主类中对象的引用应该是私有的。

我正在使用Rhino Mocks。

感谢您的帮助：）

Answer 1

如果将执行文件读取的功能放入类中，例如

FileReader : IFileReader

然后将IFileReader作为arg传递给构造函数。然后你可以嘲笑那个

Answer 2

拉出文件依赖项并在构造函数中传入IFileSomething接口。然后模拟IFileSomething并对其设定期望。

Answer 3

其他建议的替代方法是使您的代码模板化并接收可在整个类的方法中使用的FileReader类型。

template <class FileReader>
class SomeClass
{
  private: void doSomething()
  {
    FileReader fileReader;
    // Do something
  }
};

另一种方法是将方法传递给SomeClass构造函数，该构造函数返回FileReader的实现。这可以在整个类中使用，类似于模板的使用方式，但这样做，你仍然可以从IFileReader派生你的MockFileReader。

其中任何一个的问题是无法在FileReader上执行单元测试，因为SomeClass无法访问它。

n.b。上面的代码是C ++，但我知道这两种方法都适用于C＃。

Answer 4

确保您同意自己这是一个服务或商业实体。

服务通常被认可，因为它使用一组业务实体来完成某项任务，并且它本身不会维护持久数据。

商业实体是您问题域中的一个单元，您可能会在概念上坚持这样做。

如果您发现它是一项服务，您应该在构建服务时以某种方式注入依赖项。通常它可以有这样的构造函数： public MyService（IFileObject）

从main构建时： var service = new MyService（MyRealFile）

从测试设置构建时： var service = new MyService（MyMockedFiled）

如果您发现您正在测试的内容实际上是一个业务实体，那么您应该避免给实体一个依赖项。您通常这样做是退一步并在您自己和业务实体之间构建一个Service类。该服务明确地向业务实体提供其所有必要的数据。在您的情况下，这意味着该服务通过读取文件为实体提供了应该学习的内容。

因此，服务是与文件系统相关的服务，甚至可以使用另一个（专用）文件读取器业务实体来读取文件。如果您在系统中的其他位置使用它，您永远不会希望业务实体进行恶意依赖调用。他们的代码变成了上下文绑定，这是你想要避免的。商业活动应快速，独立，定义和反应迅速。

您的单元测试应该是服务，可能会通过注入获得依赖性。如果您发现自己正在对业务实体进行单元测试，那么您就缺乏服务级别。

Answer 5

感谢您的回答，我的cookie被删除了。我使用了第一个答案并在代码中稍作改动。效果很好:)）