单元测试访问器（getter 和 setter）

Question

给定以下方法：

public function setFoo($foo) {
    $this->_foo = $foo;
    return $this;
}

public function getFoo() {
    return $this->_foo;
}

假设将来它们可能会变得更复杂：

• 您将如何为这些方法编写单元测试？
• 只有一种测试方法？
• 我应该跳过这些测试吗？
• 代码覆盖率如何？
• @covers 注释怎么样？
• 也许可以在抽象测试用例中实现一些通用测试方法？

（我使用 Netbeans 7）

这似乎是在浪费时间，但我不介意 IDE 是否会自动生成这些测试方法。

致qoute from the comment of Sebastian Bergman's blog：

（这就像测试 getter 和 setter —— 失败！）。无论如何，如果他们失败了；依赖它们的方法不会失败吗？

那么，代码覆盖率呢？

Answer 1

如果你做 TDD，你应该为 getter 和 setter 写一个测试。也。不要 编写一行代码而不对其进行测试——即使你的代码是 很简单。

使用 getter 和 setter 串联是一种宗教战争 您的测试或通过使用访问受保护的类成员来隔离每个测试 您的单元测试框架功能。作为黑盒测试人员，我更喜欢 将我的单元测试代码绑定到公共 api 而不是将其绑定到 具体实施细节。我期待改变。我想鼓励 开发人员重构现有代码。类内部不应该 影响“外部代码”（在这种情况下是单元测试）。我不想打破 当内部发生变化时进行单元测试，我希望它们在公开时中断 api 更改或行为更改时。好的，好的，以防出现故障 测试并不能确定问题的唯一来源。我有 查看 getter 和 setter 以找出导致 问题。大多数时候，你的 getter 非常简单（少于 5 行 代码：例如一个返回和一个可选的空检查异常）。所以 首先检查这没什么大不了的，也不费时。并检查 二传手的快乐之路大多数时候只是多一点 复杂（即使您有一些验证检查）。

尝试隔离您的测试用例 - 为 SUT 编写测试（主题在 测试），无需依赖其他方法即可验证其正确性 （除了我上面的例子）。你越隔离测试，你的 测试发现问题。

根据您的测试策略，您可能只想覆盖快乐的路径 （务实的程序员）。或者悲伤的道路，也是。我更喜欢涵盖所有 执行路径。当我认为我发现了所有执行路径时，我会检查 代码覆盖识别死代码（不识别是否有 未发现的执行路径 - 100% 的代码覆盖率是一个误导性指标）。

黑盒测试人员最好在严格模式下使用 phpunit 并使用@covers 隐藏附带覆盖。

当你编写单元测试时，你对 A 类的测试应该独立于 B 类执行。所以你对 A 类的单元测试不应该调用/覆盖 B 类的方法。

如果您想识别过时的 getter/setter 和其他“死”方法（生产代码不使用），请使用静态代码分析。您感兴趣的指标称为“方法级别的传入耦合（MethodCa）”。不幸的是，该指标 (ca) 在 PHP Depend 中的方法级别不可用（请参阅：http://pdepend.org/documentation/software-metrics/index.html 和 http://pdepend.org/documentation/software-metrics/afferent-coupling.html）。如果您真的需要它，请随时将其贡献给 PHP Depend。排除来自同一类的调用的选项将有助于获得没有“附带”调用的结果。如果您确定一个“死方法”，请尝试确定它是否打算在不久的将来使用（与具有 @depriated 注释的其他方法的对应物），否则将其删除。如果它仅在同一类中使用，请将其设为私有/受保护。不要将此规则应用于库代码。

B 计划： 如果您有验收测试（集成测试、回归测试等），您可以在不同时运行单元测试和 phpunits 严格模式的情况下运行该测试。这可能会导致非常相似的代码覆盖率结果，就像您分析了生产代码一样。但在大多数情况下，您的非单元测试不如您的生产代码那么强大。如果此计划 B 与生产代码“足够”以获得有意义的结果，则取决于您的纪律。

进一步阅读： - 书籍：实用程序员 - 书籍：清洁代码

Answer 2

好问题，

我通常尽量不直接测试 getter 和 setter，因为我发现只测试真正做某事的方法会有更大的好处。

特别是在不使用 TDD 时，这具有向我展示我在单元测试中不使用的设置器的额外好处，向我展示我的测试不完整或不使用/不需要设置器。 “如果我可以在不使用该 setter 的情况下执行所有“真实”代码，为什么它会存在。”

当使用 fluent setter 时，我有时会编写一个测试来检查 setter 的“流畅”部分，但通常其他测试会涵盖这一点。

回答你的清单：

• 只有一种测试方法？

这是我最不喜欢的选项。全部或没有。仅测试一个对其他人来说不容易理解并且看起来“随机”或需要以某种方式记录。

评论后编辑：

是的，对于“微不足道”的 get/set 测试，我只会对每个属性使用一种方法可能根据具体情况，甚至整个类只使用一种方法（对于具有许多 getter 和我不想编写/维护很多测试）

• 您将如何为这些方法编写单元测试？
• 我应该跳过这些测试吗？

我不会跳过它们。 也许 getter 取决于你有多少（我倾向于只写我真正需要的 getter），但是完全覆盖一个类的任务不应该因为 getter 而失败。

• 代码覆盖率如何？
• @covers 注释怎么样？

对于@covers，我的看法始终是“在任何地方使用它或根本不使用它”。混合两种“风格”的测试会带走注释的一些好处，并且在我看来“未完成”。

• 也许可以在抽象测试用例中实现一些通用测试方法？

对于像值对象这样可以很好地工作的东西。一旦你通过类型提示传入对象/数组，它可能会中断（或更复杂），但我个人更喜欢它而不是为 500 个 getter 和 setter 编写手动测试。

Answer 3

这是一个常见问题，但奇怪的是在 SO 上找不到骗子。

您可以为访问器编写单元测试，但大多数从业者不会。即如果访问器没有任何自定义逻辑，我不会编写单元测试来验证字段访问是否有效。 相反，我会依靠这些访问器的消费者来确保访问器工作。例如如果 getFoo 和 setFoo 不起作用，这些方法的调用者应该中断。因此，通过为调用方法编写单元测试，访问器得到验证。

这也意味着代码覆盖率不应该成为问题。如果您在所有测试套件运行后发现未涵盖的访问器，则它们可能是多余的/未使用的。删除它们。

尝试编写一个测试来说明客户端将使用该访问器的场景。例如下面的 sn-p 显示了暂停按钮的工具提示（属性）如何根据其当前模式进行切换。

[Test]
public void UpdatesTogglePauseTooltipBasedOnState()
{
    Assert.That(_mainViewModel.TogglePauseTooltip, Is.EqualTo(Strings.Main_PauseAllBeacons));

    _mainViewModel.TogglePauseCommand.Execute(null);
    Assert.That(_mainViewModel.TogglePauseTooltip, Is.EqualTo(Strings.Main_ResumeAllBeacons));

    _mainViewModel.TogglePauseCommand.Execute(null);
    Assert.That(_mainViewModel.TogglePauseTooltip, Is.EqualTo(Strings.Main_PauseAllBeacons));
}