我也想知道。Assert的API不是很对称;对于测试对象是否相同，它提供了assertSame和assertNotSame。

当然，写起来也不算太长:

assertFalse(foo.equals(bar));

不幸的是，使用这样的断言，输出中唯一有信息的部分是测试方法的名称，因此应该单独形成描述性消息:

String msg = "Expected <" + foo + "> to be unequal to <" + bar +">";
assertFalse(msg, foo.equals(bar));

这当然是非常乏味的，最好是滚动您自己的assertNotEqual。幸运的是，将来它可能会成为JUnit: JUnit第22期的一部分

我建议你使用更新的assertThat()风格断言，它可以很容易地描述各种否定，并自动构建你所期望的描述以及如果断言失败你会得到什么:

assertThat(objectUnderTest, is(not(someOtherObject)));
assertThat(objectUnderTest, not(someOtherObject));
assertThat(objectUnderTest, not(equalTo(someOtherObject)));

这三个选项都是等效的，选择一个你觉得最易读的。

为了使用简单的方法名(并允许这种时态语法工作)，你需要这些导入:

import static org.junit.Assert.*;
import static org.hamcrest.CoreMatchers.*;

I'd argue that the absence of assertNotEqual is indeed an asymmetry and makes JUnit a bit less learnable. Mind that this is a neat case when adding a method would diminish the complexity of the API, at least for me: Symmetry helps ruling the bigger space. My guess is that the reason for the omission may be that there are too few people calling for the method. Yet, I remember a time when even assertFalse did not exist; hence, I have a positive expectation that the method might eventually be added, given that it is not a difficult one; even though I acknowledge that there are numerous workarounds, even elegant ones.

通常当我期望两个对象相等时，我这样做:

assertTrue(obj1.equals(obj2));

and:

assertFalse(obj1.equals(obj2));

当他们被认为是不平等的。我知道这不是对你问题的回答，但这是我能得到的最接近的答案。它可以帮助其他人搜索在JUnit 4.11之前的JUnit版本中可以做什么。

对于否定的断言，最好使用Hamcrest，而不是assertFalse，因为在前者中，测试报告将显示断言失败的差异。

如果使用assertFalse，只会在报告中得到一个断言失败。例如，丢失了关于失败原因的信息。

人们想要assertNotEquals()的明显原因是比较内置对象，而不必首先将它们转换为完整的对象:

详细的例子:

....
assertThat(1, not(equalTo(Integer.valueOf(winningBidderId))));
....

vs.

assertNotEqual(1, winningBidderId);

不幸的是，由于Eclipse默认情况下不包括JUnit 4.11，您必须详细说明。

注意:我不认为'1'需要包装在Integer.valueOf()中，但由于我刚从。net返回，所以不要指望我的正确性。