单元测试类风格

Question

在编写单元测试时，我总是extends Assert，因此我对许多Assert.assertXXX方法的多次调用都有无限制的访问权限：

例如：

public class MyTestClass extends Assert {
    @Test
    public void SomeTest() {
        assertNotNull(""); // instead of Assert.assertNotNull("");
    }
}

扩展Assert可以节省我输入Assert.assertNotNull("");的费用。 Assert.在我看来代码混乱，因为你经常使用它。

我的测试类很少需要扩展另一个类，如果他们这样做，我倾向于使超类扩展为Assert。

然而，感觉我打破一些编码风格只是为了避免导入和限定。

这个＆＃34;穷人＆＃34;编码风格？
它仍然是最佳实践＆＃34;代码，如果我这样做，因为它只是一个测试类？

编辑：

import static org.junit.Assert.*;

没有用，因为我的Eclipse代码格式化程序解析了所有导入，所以这样的行被删除并替换为每次保存时实际使用的所有方法的单独导入，如果我使用的话，让我重新导入新的断言方法。

不可否认，经过一段时间对测试类进行编码后，导入 new 方法的需求减少了，但在编写新的测试类时，这是一件麻烦事。

Answer 1

不，这样做：

import static org.junit.Assert.*;

public class MyTestClass {
   @Test
   public void SomeTest() {
       assertNotNull("");
   }
}

Answer 2

我个人不喜欢扩展课程，如果我不需要。 您是否考虑过使用静态导入您正在使用的方法？ 另外，我建议尝试Fest断言以获得更好，更易读的测试。

Answer 3

除非需要多态，否则扩展类是一种糟糕的风格。这样做与Sun称之为Constant Interface Antipattern的类似。正如您在该页面上看到的那样，静态导入语句被专门添加到该语言中以防止它。

就个人而言，我只写Assert.assertNotNull(value)。这不是很多打字，我觉得它不会伤害可读性。

如果您坚持使用非限定方法，则应使用静态导入导入每个方法，因为以“*”结尾的import语句也被认为是不合格的方式。如果有其他人来维护您的代码（或者如果您在六个月后再回来查看它），以“*”结尾的导入将要求维护者做一些侦探工作以确定方法的来源，而显式导入使得方法的来源立即变得清晰。

Answer 4

我遇到了同样的问题 - 但很容易解决：

像其他人一样说：

import static org.junit.Assert.*;

public class MyTestClass {
   @Test
   public void SomeTest() {
       Assert.assertNotNull("");
   }
}

---

这是最重要的部分：

转到：Window-＆gt;首选项，Java-＆gt;代码样式 - ＆gt;组织导入，“。*所需的静态导入数量（例如'java.lang.Math。*'）：” - ＆gt ;改为0。

现在您的代码格式化程序不会将“。*”导入“单个类”导入。

Answer 5

或者如果你不是'。*'的粉丝 - 进口：

Import static org.junit.Assert;

public class MyTestClass {
   @Test
   public void SomeTest() {
      Assert.assertNotNull("");
   }
}

Answer 6

首先：你问这个问题所以你也可以看到你的方式是错的:) 正如大家告诉你的那样，应该用静态导入来完成。这是正确的方式。周期。

正确的问题是如何使eclipse帮助你而不是干涉。至少有两种方法。首先，当eclipse应该扩展import xxx时，你可以设置阈值。*。只需更改它就可以获得xxx。* 另一种方法是在上下文辅助中添加断言。这样，eclipse会建议你使用你的断言而不必先导入它们。

和我的方式：不要使用junit断言。使用fest assert 2.0。你可以只是静态导入xxx.assertThat就是这样。