27

给定以下方法：

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

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

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

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

（我使用 Netbeans 7）

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

引用 Sebastian Bergman 博客的评论：

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

那么，代码覆盖率呢？

4

3 回答 3

8

如果你做 TDD，你应该为 getter 和 setter 编写一个测试。也。不要在没有测试的情况下编写一行代码——即使你的代码非常简单。

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

尝试隔离您的测试用例 - 为 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 /传入耦合.html）。如果您真的需要它，请随时将其贡献给 PHP Depend。排除来自同一类的调用的选项将有助于获得没有“附带”调用的结果。如果您确定一个“死方法”，请尝试确定它是否打算在不久的将来使用（与具有 @depriated 注释的其他方法的对应物），否则将其删除。如果它仅在同一类中使用，请将其设为私有/受保护。不要将此规则应用于库代码。

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

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

于 2013-06-30T10:00:38.217 回答
6

好问题，

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

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

当使用流利的设置器时，我有时会编写一个测试来检查设置器的“流利”部分，但通常这在其他测试中有所涵盖。

要回答您的清单：

  • 只有一种测试方法？

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

评论后编辑：

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

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

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

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

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

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

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

于 2011-02-14T08:45:01.970 回答
3

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

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

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

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

[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));
}
于 2011-02-14T05:43:15.937 回答