单元测试访问器(获取器和设置器) [英] Unit testing accessors (getters and setters)

问题描述

使用以下方法:

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

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

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

Assuming, they may be changed to be more complex in the future:

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

• How would you write unit tests for those methods?
• Just one test method?
• Should I skip those tests?
• What about code coverage?
• How about @covers annotation?
• Maybe some universal test method to implement in the abstract test case?

(我使用Netbeans 7)

(I use Netbeans 7)

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

This seems like a waste of time, but I wouldn't mind if IDE would generate those test methods automatically.

从塞巴斯蒂安·伯格曼博客的评论中 qoute :

To qoute from the comment of Sebastian Bergman's blog:

(就像测试getter和setter一样-失败！).无论如何，如果他们失败了；依赖它们的方法不会失败吗?

(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?

那么，代码覆盖率如何?

So, what about the code coverage?

推荐答案

好问题，

我通常不尝试直接测试getters和setters，因为我发现仅测试实际执行 的方法会有更大的好处.

i usually try not to test getters&setters directly since i see a greater benefit in testing only the methods that actually do something.

特别是当不使用TDD时，这还有一个额外的好处，那就是向我显示未在单元测试中使用的设置器，向我显示我的测试不完整或不使用/不需要设置器. 如果我可以在不使用该设置器的情况下执行所有真实"代码，为什么会出现在其中."

Especially when not using TDD this has the added benefit of showing me setters that i don't use in my unittests showing me that ether my tests are incomplete or that the setter is not used/needed. "If i can execute all the "real" code without using that setter why is it there."

当使用流利的塞特器时，我有时会编写一个测试来检查塞特器的流利"部分，但通常其他测试中都涵盖了这一点.

When using fluent setter i sometimes write a test checking the 'fluent' part of the setters but usually that is covered in other tests.

要回答您的列表:

• 只是一种测试方法?

那是我最不喜欢的选项.全部或全无.测试其他人不容易理解并且看起来随机"，或者需要以某种方式进行记录.

评论后

是的，对于琐碎"的获取/设置测试，根据情况，我只会对每个属性使用一个方法可能，甚至对于整个类也只能使用一种方法(对于具有许多getter和设置员，我不想编写/维护许多测试)

Yes, for "trivial" get/set testing I'd only use one method per property maybe depending on the case even only one method for the whole class (for value objects with many getters and setters I don't want to write/maintain many tests)

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

我不会跳过它们. 也许吸气剂取决于您有多少个吸气剂(我倾向于只写我实际需要的吸气剂)，但是完全覆盖类的任务不会因为吸气剂而失败.

I wouldn't skip them. Maybe the getters depending on how many you have (i tend to write only getters i actually need) but the task of having a class completely covered shouldn't fail because of getters.

• 代码覆盖率如何?
• @covers批注如何?

对于@covers，我的看法始终是在任何地方使用它，或者根本不使用它".将两种样式"的测试混合使用会消除注释的一些好处，并且对我来说看起来未完成".

With @covers my take is always "use it everywhere or don't use it at all". Mixing the two 'styles' of testing takes away some of the benefits of the annotation and looks 'unfinished' to me.

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

对于诸如值对象之类的东西，可以很好地工作.一旦使用类型提示传递对象/数组，它可能会中断(或变得更加复杂)，但我宁愿自己优先于为500个getter和setter编写手动测试.

For something like value objects that could work nicely. It might break (or gets more complicated) once you pass in objects / array with type hinting but I'd presonally prefer it over writing manual tests for 500 getters and setters.

这篇关于单元测试访问器(获取器和设置器)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！