用于hashCode / equals契约的JUnit理论 [英] JUnit theory for hashCode/equals contract
问题描述
以下类用作equals / hashCode契约的通用测试器。它是本土测试框架的一部分。
The following class serve as generic tester for equals/hashCode contract. It is a part of a home grown testing framework.
- 您怎么看?
- 我如何(强)测试这个班级?
- 这是一个很好用的Junit理论?
班级:
@Ignore
@RunWith(Theories.class)
public abstract class ObjectTest {
// For any non-null reference value x, x.equals(x) should return true
@Theory
public void equalsIsReflexive(Object x) {
assumeThat(x, is(not(equalTo(null))));
assertThat(x.equals(x), is(true));
}
// For any non-null reference values x and y, x.equals(y)
// should return true if and only if y.equals(x) returns true.
@Theory
public void equalsIsSymmetric(Object x, Object y) {
assumeThat(x, is(not(equalTo(null))));
assumeThat(y, is(not(equalTo(null))));
assumeThat(y.equals(x), is(true));
assertThat(x.equals(y), is(true));
}
// For any non-null reference values x, y, and z, if x.equals(y)
// returns true and y.equals(z) returns true, then x.equals(z)
// should return true.
@Theory
public void equalsIsTransitive(Object x, Object y, Object z) {
assumeThat(x, is(not(equalTo(null))));
assumeThat(y, is(not(equalTo(null))));
assumeThat(z, is(not(equalTo(null))));
assumeThat(x.equals(y) && y.equals(z), is(true));
assertThat(z.equals(x), is(true));
}
// For any non-null reference values x and y, multiple invocations
// of x.equals(y) consistently return true or consistently return
// false, provided no information used in equals comparisons on
// the objects is modified.
@Theory
public void equalsIsConsistent(Object x, Object y) {
assumeThat(x, is(not(equalTo(null))));
boolean alwaysTheSame = x.equals(y);
for (int i = 0; i < 30; i++) {
assertThat(x.equals(y), is(alwaysTheSame));
}
}
// For any non-null reference value x, x.equals(null) should
// return false.
@Theory
public void equalsReturnFalseOnNull(Object x) {
assumeThat(x, is(not(equalTo(null))));
assertThat(x.equals(null), is(false));
}
// Whenever it is invoked on the same object more than once
// the hashCode() method must consistently return the same
// integer.
@Theory
public void hashCodeIsSelfConsistent(Object x) {
assumeThat(x, is(not(equalTo(null))));
int alwaysTheSame = x.hashCode();
for (int i = 0; i < 30; i++) {
assertThat(x.hashCode(), is(alwaysTheSame));
}
}
// If two objects are equal according to the equals(Object) method,
// then calling the hashCode method on each of the two objects
// must produce the same integer result.
@Theory
public void hashCodeIsConsistentWithEquals(Object x, Object y) {
assumeThat(x, is(not(equalTo(null))));
assumeThat(x.equals(y), is(true));
assertThat(x.hashCode(), is(equalTo(y.hashCode())));
}
// Test that x.equals(y) where x and y are the same datapoint
// instance works. User must provide datapoints that are not equal.
@Theory
public void equalsWorks(Object x, Object y) {
assumeThat(x, is(not(equalTo(null))));
assumeThat(x == y, is(true));
assertThat(x.equals(y), is(true));
}
// Test that x.equals(y) where x and y are the same datapoint instance
// works. User must provide datapoints that are not equal.
@Theory
public void notEqualsWorks(Object x, Object y) {
assumeThat(x, is(not(equalTo(null))));
assumeThat(x != y, is(true));
assertThat(x.equals(y), is(false));
}
}
用法:
import org.junit.experimental.theories.DataPoint;
public class ObjectTestTest extends ObjectTest {
@DataPoint
public static String a = "a";
@DataPoint
public static String b = "b";
@DataPoint
public static String nullString = null;
@DataPoint
public static String emptyString = "";
}
推荐答案
要考虑的一件事:测试对象与equals合同的一致性应该涉及其他类型的实例。特别是,子类或超类的实例可能会出现问题。 Joshua Bloch对 Effective Java 中的相关陷阱给出了很好的解释(I重复使用duffymo的链接,所以他应该得到它的信任) - 请参阅涉及Point和ColorPoint类的Transitivity下的部分。
One thing to consider: testing an object's conformance to the equals contract should involve instances of other types. In particular, problems are likely to appear with instances of a subclass or superclass. Joshua Bloch gives an excellent explanation of the related pitfalls in Effective Java (I'm reusing duffymo's link, so he should get credit for it) -- see the section under Transitivity involving the Point and ColorPoint classes.
是的,你的实现没有阻止某人编写涉及子类实例的测试,但由于 ObjectTest
是一个泛型类,它给人的印象是所有数据点都应该来自一个类(该类)正在测试中)。最好完全删除类型参数。只是值得深思。
True, your implementation doesn't prevent someone from writing a test that involves instances of a subclass, but because ObjectTest
is a generic class it gives the impression that all data points should come from a single class (the class being tested). It might be better to remove the type parameter altogether. Just food for thought.
这篇关于用于hashCode / equals契约的JUnit理论的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!