AnyString() 作为单元测试的参数

AnyString() as parameter for unit test

我必须处理一个没有测试的遗留应用程序。所以在我开始重构之前,我想确保一切正常。

现在想象一下下面的情况:

public SomeObject doSomething(final OtherObject x, final String something) {
    if(x == null) throw new RuntimeException("x may not be null!");
    ...
}

现在我想测试那个 null 检查,以确保它有效并且在重构后我不会丢失它。

所以我这样做了

@Test(expected = RuntimeException.class)
public void ifOtherObjectIsNullExpectRuntimeException() {
    myTestObject.doSomething(null, "testString");
}

现在,这当然有效。

但我想传入一个随机字符串,而不是 "testString"。

所以我尝试了:

@Test(expected = RuntimeException.class)
public void ifOtherObjectIsNullExpectRuntimeException() {
    myTestObject.doSomething(null, Mockito.anyString());
}

但这是不允许的,因为我得到

org.mockito.exceptions.misusing.InvalidUseOfMatchersException: ... You cannot use argument matchers outside of verifications or stubbing

我明白这句话的意思,但我想知道我是否仍然可以在不对我的测试进行参数化之类的情况下设法做我想做的事。 我可能使用的唯一库是 Junit、AssertJ、Mockito 和 Powermock。

有什么想法吗?

好吧,我对 mockito 了解不多,但您始终可以创建自己的随机字符串生成器。也许这可以工作,你可以修改其中的更多类型的输入

测试应该是确定性的。在测试中使用随机值使得在调试失败的测试时难以重现行为。我建议您只为测试创建一个 String 常量,例如 "abcdefg".

好吧,就像 Mockito 试图通过该异常告诉您的那样,这并不是您真正使用 anyString 的方式。此类方法仅供模拟使用。

那么,为什么不尝试使用实际的随机字符串进行测试呢?在这种情况下,我个人最喜欢的是:java.util.UUID.randomUUID().toString()。这几乎总是会生成一个以前从未用于测试的全新字符串。

我还想补充一点,如果您正在为 SomeObject class 编写测试,您应该避免嘲笑 SomeObject 的行为。从你的例子来看,你并没有完全那样做,但看起来你可能会沿着那条路走下去。模拟您要测试的实现的依赖关系,而不是实现本身!这个非常重要;否则你实际上并没有在测试任何东西。

你在这里混淆了概念。

所有那些 "mocking" 助手,如 anyString() 都是为了在配置 mock 对象时使用。

但是当你检查你的测试代码时:

@Test(expected = RuntimeException.class)
public void ifOtherObjectIsNullExpectRuntimeException() {
  myTestObject.doSomething(null, "testString");
}

你会发现:这个测试完全没有涉及模拟。您只是 不能 在那个地方使用那些 Mockito 调用;因为"there is no Mockito"在那个地方。

并且只是为了记录 - 无论如何都不需要在这里过火。您的逻辑在这里非常清楚:当第一个参数为 null 时,您将抛出该异常。因此,第二个参数是什么根本无关紧要。因此,考虑一个小时如何使用任何第二个参数测试 null 在我看来是:浪费你的时间。

最后提示:有java.lang.Objects class 可以很好地检查 null,所以我的生产代码看起来像

public SomeObject doSomething(final OtherObject x, final String something) {
  Objects.requireNonNull(otherObject, "otherObject must not be null");
  Objects.requireNonNull(something, "something must not be null");

唯一的区别是:需要...抛出 NullPointerExceptions

finally:有些人建议把final放在每个参数上;但我不会那样做。它在 99% 的情况下添加 no 值。这只是意味着你有更多的代码要阅读;没有充分的理由。但这是风格问题。

编辑关于进行测试以检查未来潜在变化的评论:你不应该这样做:

  1. 在某种程度上,如何验证您的输入是一个实现细节。您不测试实现细节。也就是说:
  2. 你的方法有一定的契约(例如,你通过写一个写着 "throws NPE on null input" 的 javadoc 非正式地指定)。您的测试应该 准确地 验证当前合约。合同是:如果第一个参数为空则抛出。

也许还有另一种观点;因为我仍然认为你在这里浪费时间!您应该确保所有界面都清晰、易于理解且易于使用。它们允许您的代码的用户轻松地做正确的事情;并防止他做错事。这就是您应该关注的 - 整个界面的质量! 因此,不用担心如何为未来可能发生的变化编写测试;只需确保您的代码库整体一致即可。