assertEquals(Object, Object)
从JUnit4 / JUnit 5或 assertThat(actual, is(expected));
在其他答案中提出的Hamcrest只能同时使用,equals()
并且toString()
被比较对象的类(并深入)覆盖。
这很重要,因为断言中的相等性测试依赖equals()
并且测试失败消息依赖于toString()
比较对象。
对于诸如的内置类String
,Integer
对于...等等,没有问题,因为它们覆盖了equals()
和toString()
。因此断言List<String>
或List<Integer>
与 完全正确assertEquals(Object,Object)
。
关于这个问题:您必须equals()
在类中重写,因为在对象相等性方面它是有意义的,不仅要使使用JUnit进行测试时的断言更容易。
为了使声明更容易,您可以使用其他方法。
作为一个好习惯,我赞成断言/匹配器库。
这是一个AssertJ解决方案。
org.assertj.core.api.ListAssert.containsExactly()
就是您所需要的:它按照Javadoc中的说明,验证实际组是否恰好包含给定的值而没有其他值。
假设有一个Foo
类,您可以在其中添加元素并从中获取元素。对此
的单元测试Foo
断言这两个列表具有相同的内容,如下所示:
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
@Test
void add() throws Exception {
Foo foo = new Foo();
foo.add("One", "Two", "Three");
Assertions.assertThat(foo.getElements())
.containsExactly("One", "Two", "Three");
}
AssertJ的一个优点List
是不需要按预期声明a :它使断言更直接,代码更易读:
Assertions.assertThat(foo.getElements())
.containsExactly("One", "Two", "Three");
但是断言/匹配器库是必须的,因为它们确实会进一步发展。
假设现在Foo
不存储String
s而是Bar
s的实例。
这是非常普遍的需求。使用AssertJ,断言仍然很容易编写。更好的是,您可以断言列表内容是相等的,即使equals()/hashCode()
在JUnit方式要求这样做时不覆盖元素的类:
import org.assertj.core.api.Assertions;
import static org.assertj.core.groups.Tuple.tuple;
import org.junit.jupiter.api.Test;
@Test
void add() throws Exception {
Foo foo = new Foo();
foo.add(new Bar(1, "One"), new Bar(2, "Two"), new Bar(3, "Three"));
Assertions.assertThat(foo.getElements())
.extracting(Bar::getId, Bar::getName)
.containsExactly(tuple(1, "One"),
tuple(2, "Two"),
tuple(3, "Three"));
}
assertArrayEquals
。与结合使用List#toArray
。