我来这个派对很晚了，但我发现了表格:

static void assertTrue(java.lang.String message, boolean condition) 

可以用于大多数“不等于”的情况。

int status = doSomething() ; // expected to return 123
assertTrue("doSomething() returned unexpected status", status != 123 ) ;

我完全同意OP的观点。Assert.assertFalse(expected.equals(actual))不是表达不相等的自然方式。 但我认为，除了Assert.assertEquals()之外，Assert.assertNotEquals()还可以工作，但对于记录测试实际断言的内容以及在断言失败时理解/调试并不友好。 所以是的JUnit 4.11和JUnit 5提供了Assert.assertNotEquals()(断言. assertnotequals()在JUnit 5)，但我真的避免使用它们。

作为替代，为了断言一个对象的状态，我通常使用一个匹配器API，它可以很容易地深入对象状态，清楚地记录断言的意图，并且非常便于用户理解断言失败的原因。

这里有一个例子。 假设我有一个Animal类，我想测试createWithNewNameAndAge()方法，这个方法通过改变它的名称和年龄来创建一个新的Animal对象，但保留它最喜欢的食物。 假设我使用assert . assertnotequals()断言原始对象和新对象是不同的。 下面是一个有缺陷的createWithNewNameAndAge()实现的Animal类:

public class Animal {

    private String name;
    private int age;
    private String favoriteFood;

    public Animal(String name, int age, String favoriteFood) {
        this.name = name;
        this.age = age;
        this.favoriteFood = favoriteFood;
    }

    // Flawed implementation : use this.name and this.age to create the 
    // new Animal instead of using the name and age parameters
    public Animal createWithNewNameAndAge(String name, int age) {
        return new Animal(this.name, this.age, this.favoriteFood);
    }

    public String getName() {
        return name;
    }

    public int getAge() {
        return age;
    }

    public String getFavoriteFood() {
        return favoriteFood;
    }

    @Override
    public String toString() {
        return "Animal [name=" + name + ", age=" + age + ", favoriteFood=" + favoriteFood + "]";
    }

    @Override
    public int hashCode() {
        final int prime = 31;
        int result = 1;
        result = prime * result + age;
        result = prime * result + ((favoriteFood == null) ? 0 : favoriteFood.hashCode());
        result = prime * result + ((name == null) ? 0 : name.hashCode());
        return result;
    }

    @Override
    public boolean equals(Object obj) {
        if (!(obj instanceof Animal)) return false;

        Animal other = (Animal) obj;
        return age == other.age && favoriteFood.equals(other.favoriteFood) &&
                name.equals(other.name);
    }

}

JUnit 4.11+(或JUnit 5)作为测试运行器和断言工具

@Test
void assertListNotEquals_JUnit_way() {
    Animal scoubi = new Animal("scoubi", 10, "hay");
    Animal littleScoubi = scoubi.createWithNewNameAndAge("little scoubi", 1);
    Assert.assertNotEquals(scoubi, littleScoubi);
}

测试如预期的那样失败了，但是提供给开发人员的原因并没有什么帮助。它只是说值应该是不同的，并输出在实际的Animal参数上调用的toString()结果:

assertionerror:值应该不同。实际:动物 [name=scoubi, age=10, favoriteFood=hay] org.junit.Assert.fail (Assert.java: 88)

两个对象是不相等的。但问题在哪里? 在测试的方法中，哪个字段的值不正确?一个?两个?全部吗? 为了发现它，你必须深入createWithNewNameAndAge()实现/使用调试器，而测试API将更友好，如果它能让我们之间的期望和得到的差异。

JUnit 4.11作为测试运行器，测试Matcher API作为断言工具

这里是相同的测试场景，但使用AssertJ(一个优秀的测试匹配器API)来断言动物状态:

import org.assertj.core.api.Assertions;

@Test
void assertListNotEquals_AssertJ() {
    Animal scoubi = new Animal("scoubi", 10, "hay");
    Animal littleScoubi = scoubi.createWithNewNameAndAge("little scoubi", 1);
    Assertions.assertThat(littleScoubi)
              .extracting(Animal::getName, Animal::getAge, Animal::getFavoriteFood)
              .containsExactly("little scoubi", 1, "hay");
}

当然，测试仍然失败，但这一次的原因很清楚:

java.lang.AssertionError: 期望: <["scoubi"， 10， "hay"]> 精确地包含:精确地包含(以相同的顺序): <["little scoubi"， 1， "hay"]> 但有些元素没有被发现: <["little scoubi"， 1]> 还有一些是意料之外的: (“scoubi”,10)< > 在junit5.MyTest.assertListNotEquals_AssertJ (MyTest.java: 26)

对于返回的Animal的Animal::getName, Animal::getAge, Animal::getFavoriteFood值，我们期望有这些值:

"little scoubi", 1, "hay" 

但是我们有这些价值观:

"scoubi", 10, "hay"

所以我们知道在哪里调查:名字和年龄的值是不正确的。 此外，在断言Animal::getFavoriteFood()中指定干草值的事实也允许更精确地断言返回的Animal。我们希望对象对于某些属性是不同的，而不是每个属性都是相同的。 因此，使用匹配器API无疑更加清晰和灵活。

我也想知道。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期的一部分

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.

我建议你使用更新的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.*;

JUnit 4.11中有一个assertNotEquals: https://github.com/junit-team/junit/blob/master/doc/ReleaseNotes4.11.md#improvements-to-assert-and-assume

import static org.junit.Assert.assertNotEquals;