对于除了其他方法之外还有几个setter和getter的类，考虑到在测试接口的其余部分时会调用它们，是否合理地节省了为访问器编写单元测试的时间？
答案 0 :(得分：16)
如果他们做的不仅仅是设置或返回变量，我只会对它们进行单元测试。在某些时候，您需要相信编译器将为您生成正确的程序。
答案 1 :(得分：7)
绝对。单元测试的想法是确保更改不会以未知方式影响行为。您可以通过不为getFoo()编写测试来节省一些时间。如果您将Foo的类型更改为更复杂的东西，那么您很容易忘记测试访问者。如果你质疑是否应该写一个测试，你最好不要写它。
恕我直言，如果您正在考虑跳过为方法添加测试，您可能想问自己该方法是否必要。为了充分披露，我是那些人中的一员，只有在证明有必要时才添加二传手或吸气剂。您会惊讶地发现，在构建之后您真的不需要访问特定成员，或者您只想访问一些真正依赖于成员的计算结果。但我离题了。
一个好的口头禅是总是添加测试。如果您认为不需要，因为该方法很简单，请考虑删除该方法。我意识到常见的建议是，跳过“琐碎”方法的测试是可以的，但你必须问自己这个方法是否是必要的。如果您跳过测试，则表示该方法始终是微不足道的。请记住，单元测试还可以作为 intent 和合同提供的文档。因此，一个简单方法的测试表明该方法确实意味着微不足道。
答案 2 :(得分：3)
我的测试标准是每一段包含条件逻辑的代码（如果，等等）都要进行测试。如果访问者是简单的getter / setter，我会说测试它们会浪费你的时间。
答案 3 :(得分：3)
您不必为不包含逻辑的属性编写测试。
测试简单属性的唯一解释是提高测试覆盖率 - 但这只是愚蠢。
答案 4 :(得分：2)
我认为节省时间并且不编写您认为不会特别有帮助的单元测试是合理的。
虽然100％的测试覆盖率是一个令人钦佩的理想，但在某些时候你会遇到收益递减的问题，而你花在编写测试上的时间并不值得你获得它的好处。
如果您发现自己认为有用的情况，可以随时返回并添加更多单元测试。
答案 5 :(得分：2)
我们公司有各种各样的人和意见。我倾向于不专门测试它们，因为它们通常是
但也有例外：
这两种情况可能让我测试它们。第一个比第二个多。
答案 6 :(得分：2)
没有friggin的方式！ 浪费时间！
即使是鲍勃·马丁See SO podcast 41，敏捷的祖父也说不。
答案 7 :(得分：1)
如果您的IDE生成并管理成员访问者的修改 - 您不会做任何特殊的事情 - 那么测试它们并不重要;类型将匹配，命名将通过模板等。
答案 8 :(得分：1)
我认为大多数人会说测试它们是浪费你的时间。在99％的情况下是真的。如果访问者中存在错误而其他单元测试没有间接捕获，那么我就开始质疑为什么该属性存在。
另一方面，测试一个访问器需要更少的输入，问这个问题：）
我个人测试它们。但对我来说这是一个灰色的区域，只要他们对课程的功能有足够的报道，我就不会在我的小组中按其他人来测试它们。
答案 9 :(得分：1)
通常当我考虑编写单元测试时，我会问自己以下内容：
如果是，那么我将包括单元测试。以防万一，因为如果在将来的某个时候你决定实现延迟加载，或者比简单的get / set更高级的东西，那么你需要确保它正常工作。
getter的最佳做法是不允许它们抛出异常。塞特是另一回事。但是，无论哪种方式，如果您确定某个属性可能会抛出异常，那么请为该属性编写单元测试，以便成功访问，并有目的地生成异常。
除此之外，我不会打扰，正如Dan指出的那样，“在某些时候，你需要相信编译器会为你生成正确的程序。”
答案 10 :(得分：0)
我喜欢为他们进行单元测试。如果访问者除了返回一个字段之外还做任何工作，那么该代码将被适当地测试。
即使给定的访问者除了返回一个字段之外没有做任何事情，也可能稍后修改它以做额外的事情。
此外，这是一种简单的方法来提高正在运行的测试数量，许多经理都喜欢这样做。