有人知道为什么JUnit 4提供assertEquals(foo,bar)方法而不提供assertNotEqual(foo,bar)方法吗?

它提供了assertNotSame(对应于assertSame)和assertFalse(对应于assertTrue),所以它们没有包含assertnotqual似乎很奇怪。

顺便说一下,我知道JUnit-addons提供了我正在寻找的方法。我只是出于好奇才问的。


当前回答

Modulo API一致性,JUnit不提供assertNotEquals()的原因与JUnit从未提供类似方法的原因相同

assertStringMatchesTheRegex(regex, str) vs. assertStringDoesntMatchTheRegex(regex, str) assertStringBeginsWith(prefix, str) vs. assertStringDoesntBeginWith(prefix, str)

也就是说,为断言逻辑中可能需要的东西提供特定的断言方法是无止境的!

更好的方法是提供可组合的测试原语,如equalTo(…)、is(…)、not(…)、regex(…),并让程序员将这些原语拼凑在一起,以获得更好的可读性和合理性。

其他回答

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;

Modulo API一致性,JUnit不提供assertNotEquals()的原因与JUnit从未提供类似方法的原因相同

assertStringMatchesTheRegex(regex, str) vs. assertStringDoesntMatchTheRegex(regex, str) assertStringBeginsWith(prefix, str) vs. assertStringDoesntBeginWith(prefix, str)

也就是说,为断言逻辑中可能需要的东西提供特定的断言方法是无止境的!

更好的方法是提供可组合的测试原语,如equalTo(…)、is(…)、not(…)、regex(…),并让程序员将这些原语拼凑在一起,以获得更好的可读性和合理性。

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

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

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

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

我在java 8环境下的JUnit工作,使用jUnit4.12

对我来说:编译器无法找到方法assertNotEquals,即使当我使用 进口org.junit.Assert;

所以我改变assertNotEquals("addb",字符串);assertNotEquals(“addb”字符串);

因此,如果您面临关于assertNotEqual不被识别的问题,则将其更改为Assert.assertNotEquals(,);它应该能解决你的问题

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.