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.htmlhttp://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 回答