php - 单元测试访问器(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 :

(it's like testing getters and setters -- fail!). In any case, if they were to fail; wouldn't the methods that depend on on them fail?

那么，代码覆盖率呢？

Answer 1

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

使用 getter 和 setter 串联是一种宗教 war 您的测试或通过使用访问 protected 类成员来隔离每个测试您的单元测试框架功能。作为黑盒测试人员，我更喜欢将我的单元测试代码绑定(bind)到公共(public) api 而不是将其绑定(bind)到具体实现细节。我期待改变。我想鼓励开发人员重构现有代码。类内部不应该影响“外部代码”(在这种情况下是单元测试)。我不想打破当内部发生变化时进行单元测试，我希望它们在公开时中断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 注释的其他方法的对应物)，否则将其删除。如果它仅在同一类中使用，请将其设为私有(private)/ protected 。不要将此规则应用于库代码。

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

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