Question

老师希望我们进行全面的单元测试。对我来说，这将是我第一次使用JUnit。我对测试set和get方法感到困惑。你认为我应该测试它们吗？如果答案是肯定的;这段代码足以进行测试吗？

  public void testSetandGet(){
    int a = 10;
    Class firstClass = new Class();
    firstClass.setValue(10);
    int value = firstClass.getValue();
    Assert.assertTrue("Error", value==a);
  }

在我的代码中，我认为如果有错误，我们无法知道错误是由于setter或getter而导致的。

Answer 1

我会说不要为setter和getter编写单元测试，除非你的setter和getter包含程序逻辑（在调用setter或getter时计算的东西）。

在一个真实的项目中，你将拥有更多的程序逻辑来进行单元测试，而不必测试像setter和getter这样的小事。

Answer 2

Roy Osherove在他的着名着作“单位测试的艺术”中说：

属性（Java中的getter / setter）是通常不包含任何逻辑的代码的良好示例，并且不需要测试。但请注意：一旦在属性中添加任何检查，您将需要确保正在测试逻辑。

您正在测试您设置的内容，也可以“获取”。将您的Assert声明更改为：

Assert.assertTrue(a, true);

此外，如果您打算使用它，则应通过a。

Answer 3

我认为如果你有一些条件，这很重要。例如，如果它返回异常，如果你的int必须是正数或其他条件。但如果它只是一个变量赋值，我认为它没有用......对于吸气剂来说也是一样。

Answer 4

如果我是你，我会首先set对我正在测试的类中的属性赋值，然后我将确保get方法返回相同的值。

public void testSetandGet(){
    int a = 10;
    Class firstClass = new Class();
    firstClass.setValue(10);
    int value = firstClass.getValue();
    Assert.assertEquals(value, a);
}

Answer 5

不要对任何依赖被测试类之外的东西进行单元测试。

如果你的getter和setter是微不足道的，那么只有当底层的JVM /编译器失败时它们才会失败 - 所以你实际上是在测试JVM /编译器，而不是你的代码。

Answer 6

如果你想测试它，你可以暂时将变量公开，然后：

firstClass.setMyInt(5);
Assert.assertTrue(5, firstClass.myInt);

然而，getter和setter可以自动生成，它们通常只包含方法中的一行，如果它们导致代码失败，则可能会遇到更大的问题。单元测试不常用来测试吸气剂和定位器，你可以避免测试它们，你的单元测试仍然是全面的。

制定者和吸气剂的单元测试

6 个答案: