Question

我无法确认是否要进行这些测试。似乎set和get方法非常简单，例如：

setA(String A) {
    this.A = A;
} 

getA(){
    return A;
}

任何想法都将不胜感激！

谢谢，约瑟夫

Answer 1

我在野外看到了很少有吸气剂和固定器的问题，只有其中一个可以通过单元测试检测到，只有当所有吸气剂和固定剂都在一起进行测试时，而不是通过个人测试方法。

考虑从两对不同的getter / setter中重用相同字段的复制/粘贴错误。即，

public void setA(Object a) {
  this.a = a;
}
public Object getA() {
  return a;
}

public void setB(Object a) {
  this.a = a;
}
public Object getB() {
  return a;
}

一次关注一个setter / getter对的单元测试不会暴露问题。

现代IDE将根据请求生成getter和setter，因此这个错误不大可能，但不是每个人都使用现代IDE。（vi用户创建了上面的错误。）如果这些方法驻留在一个简单的数据持有者对象中，问题可能只会显示在远离原因的位置。

出于这个原因，如果我测试getter和setter（我经常不这样做），那么它来自一个测试方法，它首先使用不同的值调用所有setter，然后在所有getter上进行断言。 / p>

然而，你必须面对的一个问题是，当其他人得到代码并决定时，无法保证以“简单”的getter或setter开始生活的方法将保持这种状态，比方说，吸气剂是一个好的地方做一些涉及副作用的事情。

Answer 2

一般规则：为getter和setter编写测试没什么意义。只有他们有一些额外的逻辑，即。不是纯粹的访问者，你应该编写测试。

Answer 3

我唯一一次专门为set（）和get（）方法编写测试，就是它们内部存在某种逻辑。例如。将整数限制在1到8之间


public void SetA(int a)
{
  if(a > 8 || a < 1)
  {
    throw new IndexOutOfBoundsException();
  }

  this.a = a;
}

即使上面的代码是一个非常简单的例子，当你使用这种类型的逻辑时，对它们运行测试也是一个好主意。主要用于当您的业务规则发生变化时，您必须将其限制在9到1之间：）

Answer 4

进行成本/收益分析

会有什么收获

知道私有变量确实可以读/写

费用是多少

编写测试用例所需的时间
每次执行测试套件时花费的时间

如果你知道没有可观察到的副作用调用吸气剂或二传手，我就不会打扰了。

Answer 5

是的，在你的情况下，它们是微不足道的 - 但另一方面 - 两个简单的测试完全依赖于质量指标; - ）

我会创建测试。您的应用程序实际上依赖于方法实际存储/访问字段值的行为，并且不会更改任何内容。

也许，有一天有人决定更改字段类型或将一些单位转换代码添加到setter / getter中 - 测试将显示，如果代码仍然有效或者显示，则需要更多工作。

Answer 6

聪明人曾经说过“直到恐惧变成无聊才进行测试”。如果您不再担心超简单代码会破坏，请不要编写测试，除非您不厌倦编写这些测试。并且不要只是为了“改善你的指标”来编写测试，而这只是游戏系统。编写测试以确保您的代码有效，提高稳健性，并建立您可以自由重构的信心。

Answer 7

它们都是一样的，我说像空白接口或业务类。预处理应该启用所有需要的或者它们是其他类型（两者都应该返回，如响应并采取2个变量）语言（即使POSIX退出，现在无效应该使用参数，因为知道方式非常重要）

Answer 8

为不能失败的方法编写测试用例似乎与我不成比例。仅当A的值由配置或可能失败的东西初始化时值得测试。

编辑：如果帐户余额变为负数并且您想在调用方法withdraw（）之后检查标志是否设置正确，则测试有意义的另一个示例可能是标记“透支”。

Answer 9

单元测试应该是系统应该如何工作的文档。虽然人们经常跳过属性的单元测试，因为功能很简单，如果测试是文档，特别是如果其他人要进行实现，那么应该编写属性测试。也就是说，当我同时编写测试并执行实现时，我通常会跳过为属性编写测试，除非他们做的不仅仅是简单的获取/设置或者我有空闲时间，这是一件罕见的事情。

我应该在什么条件下测试get（）和set（）方法？

9 个答案: