单元测试访问器(getter和setter)

Question

鉴于以下方法：

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

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

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

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

(我使用Netbeans 7)

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

转到从塞巴斯蒂安·伯格曼博客的评论

(这就像测试getter和setters失败！)无论如何，如果它们失败了，依赖它们的方法不会失败吗？

那么，代码覆盖率呢？

Answer 1

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

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

试着隔离您的测试用例--为SUT (正在测试的主题)编写一个测试，该测试可以在不发布其他方法的情况下验证它的正确性(除了我上面的例子)。隔离测试越多，测试发现的问题就越多。

根据您的测试策略，您可能只希望涵盖愉快的路径(务实的程序员)。或者悲伤的痛苦。我更喜欢涵盖所有的执行过程。当我认为我发现了所有的执行路径时，我会检查代码覆盖率以识别死代码(而不是识别是否有未发现的执行路径- 100%的代码覆盖率是一个误导指示符)。

黑匣子测试人员最好在严格模式下使用phpunit，并使用@覆盖物隐藏担保品覆盖范围。

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

如果您想要识别过时的getter/setter和其他“死”方法(这些方法没有被生产代码使用)，请使用静态代码分析。您感兴趣的度量称为“方法级别的传入耦合(MethodCa)”。不幸的是，在PHP中，这个度量(ca)在方法级别上是不可用的(参见：http://pdepend.org/documentation/software-metrics/index.html和http://pdepend.org/documentation/software-metrics/afferent-coupling.html)。如果您确实需要它，请随意将它贡献给PHP依赖。将调用排除在同一个类之外的选项将有助于在没有“附带”调用的情况下获得结果。如果您识别了一个“死方法”，试着找出它是否打算在不久的将来使用(另一个具有@depricated注释的方法的对应方法)，否则删除它。如果它仅在同一个类中使用，则将其私有化/受保护。不要将此规则应用于库代码。

计划B:如果你有验收测试(集成测试，回归测试，等等)您可以在不同时运行单元测试的情况下运行该测试，并且不需要phpunits严格模式。这可能会导致非常类似的代码覆盖结果，就好像您已经分析了生产代码一样。但是在大多数情况下，您的非单元测试并不像生产代码那样强大。这取决于您的纪律，如果此计划B与生产代码“相等”，以获得有意义的结果。

进一步阅读：-图书:实用程序员-书:干净的代码

Answer 2

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

您可以为访问器编写单元测试，但大多数实践人员不这样做。也就是说，如果访问器没有任何自定义逻辑，我就不会编写单元测试来验证字段访问是否有效。相反，我将依赖这些访问器的使用者来确保访问器工作。如果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));
}