c++ - 在工厂方法中测试对象的创建

Question

目前我正在编写一个测试驱动的项目，我坚持测试以下行为。

我有一个名为 Menu 的界面，可以通过 addEntry 方法向其中动态添加条目。还有另一个包含 Menu 对象的类。我们称它为 MenuPresenter。当调用特定方法(例如 someAction(string title))时，MenuPresenter 应该实例化一个带有接收到的标题的 Entry 对象并将其添加到Menu 对象。 Entry 对象的实例化发生在 MenuPresenter 内的工厂方法中。

测试的行为应该是WhenSomeActionIsCalledShouldAddAnEntryContainingTitleToMenu

但是我没有找到编写测试的正确方法。我想出了两种主要的可能性来测试它，但实际上我不喜欢这两种可能性，因为(稍后)提到的缺点。

1. 实现一个继承自 Menu 的 MenuSpy，它有一个 getAddedEntry 方法。像这样，您可以提取添加的 Entry 并检查对象的状态
   EXPECT_TRUE(entry->getTitle() == title);

缺点:要检查 Entry 对象的状态，我必须使用仅用于测试原因的 getter 方法扩展接口(interface)的 API，或者使用公共(public)成员变量。这允许每个客户端访问每个Entry 实现的内部结构。因此，客户端与内部结构耦合。

1. 通过一个EntryFactory接口(interface)扩展系统，该接口(interface)有一个
   makeEntry(std::string title)-方法。像这样可以实现 EntryFactorySpy 并可以检查是否使用正确的参数(标题)调用了 makeEntry 方法。在另一个测试中，我们可以实现一个 EntryFactoryStub，它返回一个特定的 Entry 对象。然后我们可以检查(通过 MenuSpy)MenuPresenter 是否已将从工厂接收到的条目添加到菜单中。然后在工厂的单元测试中测试 Entry 对象的实例化。

缺点:因为我测试了工厂的makeEntry方法的调用，使用工厂创建条目的算法是固定的。该测试与 MenuPresenter 的内部结构紧密耦合。更改算法(例如，现在使用工厂方法会破坏测试，否则应用程序的预期行为会中断。

对于应用程序的行为而言，MenuPresenter 是否使用 EntryFactory 创建 Entry 本身应该不重要。这就是为什么我更喜欢第一种方式。但我不希望客户端的 Entry 仅仅因为测试原因而耦合到 Entry 的内部结构。

这只是我的问题的一个例子。实际上，条目不仅是用字符串创建的。它获取其他复杂对象作为 shared_ptr。这是我不想使用公共(public) getter 方法的另一个原因。像这样可以从 Entry 中提取复杂对象并更改它(是的，我可以给出一个 const shared_ptr，但这对我来说似乎不是一个好习惯。)

问题是，有人知道解决我的问题的测试模式或解决方案吗？意思是测试是否将正确的 Entry 对象添加到 Menu 对象，而没有紧密耦合到算法或 Entry 的内部结构？

Answer 1

我是一名 Java 开发人员，我从未在 C++ 中使用过 TDD，但我也许可以像您上面提到的那样描述您想要测试的内容。

在经典 TDD 中，MenuPresenter正如 Martin Fowler 在 Test Isolation 中所说，应该更像是一个小型集成测试。 .

In essence classic xunit tests are not just unit tests, but also mini-integration tests. As a result many people like the fact that client tests may catch errors that the main tests for an object may have missed, particularly probing areas where classes interact.

在经典 TDD 中尽可能使用真实对象和 Test Double如果测试的时候用真品不好意思MenuPresenter .所以问问自己，当 Entry 时会发生什么预期效果？添加在 Menu .测试 Menu将添加标题为 Entry 的标题only 是没有意义的，你应该测试在 Entry 之后影响的行为是什么添加。假设一个Entry添加将显示为标题 MenuItem ，因此您只需断言真实的 Menu是否显示 MenuItem 的对象具有预期的标题。

确实，WhenSomeActionIsCalledShouldAddAnEntryContainingTitleToMenu测试已经暴露 someAction通过名称实现细节，并将测试与实现耦合 someAction ，另一方面，当您更改 someAction 的算法时测试将失败。您可以将测试添加为 displaysAnTitltedMenuItemInMenuWhenSomeActionIsCalledWithinATitle .

如您所见，测试无论如何都会耦合到实现。我们唯一能做的就是让测试与实现的耦合尽可能低，这样，当实现发生变化时，我们只需更改一点测试即可。

如果您找到 Menu是一个尴尬的，你可以使用 MenuSpy相反，然后写一些 IntegrationContractTest在 MenuSpy 内& MenuImpl .如您所见，测试使用 MenuSpy与实际的 Menu 相比，与实现的耦合度更高一些，因为我们期望标题为 Entry添加于 MenuSpy不是 Menu 的影响在标题为 Entry 之后添加。

让MenuSpy检查标题是否为 Entry已添加，例如:

someAction(title);

menuSpy->hasReceivedATitledEntry(title);

或:您可能正在检查添加的 Entry是否是 CheckableEntry在getAddedEntryTitle标题返回前的方法。

someAction(title);

EXPECT_TRUE(menuSpy->getAddedEntryTitle() == title);