我想测试一个列表是否包含一个对象的实例。
例如,对于单个实例:
assertThat(mylist).containsExactly(Matchers.any(ExpectedType.class));
从测试
obj
返回的数组确实包含实例 ExpectedType
的一个对象。
但是我的测试失败了:
java.lang.AssertionError:<[ExpectedType@7c781c42]> 不完全包含 <[an instance of ExpectedType]>。它丢失了<[an instance of ExpectedType]>并且有意想不到的物品<[ExpectedType@7c781c42]>
我怎么写这个测试?
您正在尝试使用 Hamcrest
andTruth 编写测试以查看
List
是否恰好包含特定类的一个实例。相反,您应该使用 either Hamcrest or Truth 编写此测试。 Hamcrest 和 Truth 都是使测试更具表现力的库,每个库都有自己特定的用法、风格和语法。如果愿意,您可以在测试中将它们并排使用,但是将它们的方法链接在一起是行不通的。 (也许你感到困惑,因为两个库都可以有以 assertThat
开头的断言?)所以对于这个特定的测试,你需要选择其中一个并继续它。
然而,这两个库都缺乏检查
List
是否有一个 且只有一个 项满足条件的内置功能。因此,无论使用哪个库,您都有两个选择:您可以对列表进行一些预处理,以便可以使用内置断言,或者您可以扩展库的语言以赋予它此功能。
以下是一个示例类,演示了两个库的两个选项:
import com.google.common.collect.FluentIterable;
import com.google.common.truth.*;
import org.hamcrest.*;
import org.junit.Test;
import java.util.*;
import static com.google.common.truth.Truth.assertAbout;
import static com.google.common.truth.Truth.assert_;
import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.*;
public class ExactlyOneInstanceTest {
List<Object> myList = Arrays.asList("", 3, 'A', new Object());
@Test
public void hamcrestBuiltInTestExactlyOneInstance() {
long theNumberOfStringsInMyList = myList.stream().filter(o -> o instanceof String).count();
assertThat(theNumberOfStringsInMyList, equalTo(1L));
}
@Test
public void hamcrestExtendedTestExactlyOneInstance() {
assertThat(myList, HasExactlyOne.itemThat(is(instanceOf(String.class))));
}
@Test
public void truthBuiltInTestExactlyOneInstance() {
long theNumberOfStringsInMyList = myList.stream().filter(o -> o instanceof String).count();
// can't static import Truth.assertThat because of name clash,
// but we can use this alternative form
assert_().that(theNumberOfStringsInMyList).isEqualTo(1);
}
@Test
public void truthExtendedTestExactlyOneInstance() {
assertAbout(iterable()).that(myList).containsExactlyOneInstanceOf(String.class);
}
// Hamcrest custom matcher
static class HasExactlyOne<T> extends TypeSafeDiagnosingMatcher<Iterable<? super T>> {
Matcher<? super T> elementMatcher;
HasExactlyOne(Matcher<? super T> elementMatcher) {
this.elementMatcher = elementMatcher;
}
@Factory
public static <T> Matcher<Iterable<? super T>> itemThat(Matcher<? super T> itemMatcher) {
return new HasExactlyOne<>(itemMatcher);
}
@Override
public void describeTo(Description description) {
description
.appendText("a collection containing exactly one item that ")
.appendDescriptionOf(elementMatcher);
}
@Override
protected boolean matchesSafely(Iterable<? super T> item, Description mismatchDescription) {
return FluentIterable.from(item).filter(o -> elementMatcher.matches(o)).size() == 1;
}
}
// Truth custom extension
static <T> SubjectFactory<ExtendedIterableSubject<T>, Iterable<T>> iterable() {
return new SubjectFactory<ExtendedIterableSubject<T>, Iterable<T>>() {
@Override
public ExtendedIterableSubject<T> getSubject(FailureStrategy fs, Iterable<T> target) {
return new ExtendedIterableSubject<>(fs, target);
}
};
}
static class ExtendedIterableSubject<T> extends IterableSubject<ExtendedIterableSubject<T>, T, Iterable<T>> {
ExtendedIterableSubject(FailureStrategy failureStrategy, Iterable<T> list) {
super(failureStrategy, list);
}
void containsExactlyOneInstanceOf(Class<?> clazz) {
if (FluentIterable.from(getSubject()).filter(clazz).size() != 1) {
fail("contains exactly one instance of", clazz.getName());
}
}
}
}
尝试运行并查看该类并使用对您来说最自然的方式。在编写未来的测试时,只需尝试坚持使用可用的内置断言,并尝试使
@Test
方法的意图及其断言立即可读。如果您发现您多次编写相同的代码,或者测试方法不是那么容易阅读,那么重构和/或扩展您正在使用的库的语言。重复直到所有内容都经过测试并且所有测试都易于理解。享受吧!
更简单的解决方法是
for (Object elt : myList) {
assertThat(elt).isInstanceOf(ExpectedType.class);
}
heenenee的回答更优雅:
assertThat(iterable()).that(myList).containsInstancesOf(ExpectedType.class);
IterableSubject.containsExactly()
断言输入“完全包含提供的对象或失败。”这意味着 - 即使您可以在此处传递 Matcher
对象 - 我们断言列表恰好包含一个ExpectedType
实例。现有答案均未正确执行该不变性(相反,heenenee 的方法断言了 ExpectedType
的一个实例和任意数量的其他实例,并且您的解决方案断言该列表包含 任意数量 ExpectedType
的实例)。当我读到你的问题时,你确实打算断言 exactly-one 属性,但不管这表明已接受的解决方案存在问题——它可能会意外地导致你不打算做出的断言。
当我像这样遇到 Truth API 的限制时,我总是尝试的第一件事就是将断言简单地拆分为单独的步骤。这通常被证明易于编写、易于阅读,并且通常不会出错。可以理解的是,人们经常试图用 Truth 寻找优雅的单线,但一般来说连续断言没有错.
在这里很难击败该策略:
assertThat(ls).hasSize(1);
assertThat(Iterables.getOnlyElement(ls)).isInstanceOf(String.class);
如果可迭代对象的大小不是 1,我们将得到一个错误提示(以及可迭代对象的内容)。如果是,我们断言唯一的元素是
String
的一个实例。完成!
对于 n 实例的一般情况,代码确实变得有点混乱,但它仍然是合理的。我们只是使用
assertWithMessage()
在 isInstanceOf()
断言中包含关于列表的额外上下文:
assertThat(ls).hasSize(n);
for (int i = 0; i < ls.size(); i++) {
assertWithMessage("list: %s - index: %s", ls, i)
.that(ls.get(i)).isInstanceOf(String.class);
}
这比实现您自己的自定义
Subject
. 更具可读性,也更清楚正确
从 Truth 0.29 开始,您可以使用“Fuzzy Truth”AKA
Correspondence
做得更好。这允许您从本质上描述集合的某些转换,然后断言该转换的结果。在这种情况下,我们将创建一个INSTANCEOF_CORRESPONDENCE
:
private static final Correspondence<Object, Class<?>> INSTANCEOF_CORRESPONDENCE =
new Correspondence<Object, Class<?>>() {
@Override
public boolean compare(@Nullable Object actual, @Nullable Class<?> expected) {
return expected.isInstance(actual);
}
@Override
public String toString() {
return "is instanceof";
}
};
现在你可以写一个漂亮的单行!
assertThat(ls).comparingElementsUsing(INSTANCEOF_CORRESPONDENCE)
.containsExactly(String.class);
这种方法相对于自定义主题的最大好处是它更具可扩展性——如果您决定做出不同的断言,
Correspondence
实现不需要改变,只需改变您的断言:
assertThat(ls).comparingElementsUsing(INSTANCEOF_CORRESPONDENCE)
.doesNotContain(Integer.class);
还有 暂定计划 支持方法引用和 lambdas
.comparingElementsUsing()
这样你就可以写这样的东西:
assertThat(ls).comparingElementsUsing((o, c) -> c.isInstance(o), "is instanceof")
.containsExactly(String.class);
很老的答案,但在 AssertJ 中你可以这样做:
assertThat(myList)
.allMatch(elem -> elem instanceof ExpectedType);