Tests + Fixes for Equals/Hashcode/toString of Conditions #276

Merged
merged 21 commits into from Jun 11, 2013

Projects

None yet

3 participants

@avandeursen
Member

Wrote (parameterized) test suite for equals/hashCode/toString in the Condition class hierarchy, in new test class ConditionTest.

Fixed equals/hashCode/toString of the 11 classes providing Condition implementations by

  • Removing super calls to Object.{equals, hashCode, toString}
  • Adding the class-object itself to the computation of the hashCode
  • Replacing arguments without equals method to their .toString counter parts in equals calls

The equals/hashCode methods in the Condition hierarchy now behave nicely.

As a bonus I removed some unnecessary AtomicInteger from CountCondition (which is quite tricky anyway as the check method has a side effect). Also, the counter itself is not included in the equality check atm.

Some refactoring of the Condition hierarchy is in place though -- see also issue #275.

avandeursen added some commits May 27, 2013
@avandeursen avandeursen Typo in comment. 512a896
@avandeursen avandeursen Wrote test cases for equality, and fixed equality in RegexCond
Wrote test cases to ensure consistency between hashCode, toString, 
and equals. Had to fix RegexCond accordingly.

Removed the super.equals, super.hashcode, and super.toString calls,
since these revert back to Object, which in turn gives pointer
equivalence. (Such super calls are only useful if the superclass 
defines structurally equivalence as well).

Since the Pattern class has no structural equivalence, I replaced
the Pattern equality check used in equals by an equality check on
the String representation.

Todo: 

* fix other condition Condition classes having same problem;
* turn test cases into parameterized test covering all Conditions.
36d13ed
@avandeursen avandeursen Turned ConditionTest into parameterized test. 497ac93
@avandeursen avandeursen Added test case for NotRegexCond, and fixed its hashcode/equals impl. fd449b0
@avandeursen avandeursen Test case for UrlCondition, and fixed its hashcode/equals method b2920a7
@avandeursen avandeursen Test case for NotUrlCondition, and fix for its equality/hashcode. eb422fb
@avandeursen avandeursen Testcase for (Not)XPathCondition + fix of equals/hashcode.
Also added explanatory string in Parameterized test case.
3f058a3
@avandeursen avandeursen Test cases for VisibleCondition + fix for equality/hashcode 425a525
@avandeursen avandeursen Tests for NotVisibleCondition + fix for equals/hashcode. 6686fc4
@avandeursen avandeursen Test for JavaScriptCondition + fix for equality / hashcode. 68b71c8
@avandeursen avandeursen Improved comment. 47e05de
@avandeursen avandeursen Equals/hashcode/toString and tests for Logic.not 6a8381e
@avandeursen avandeursen Equal/hashcode/toString and tests for Logic.and a073dd0
@avandeursen avandeursen Added 9 failing test cases if args are same but constructor differs
Hashcode should not only look at the fields, but also at itself.
62ed501
@avandeursen avandeursen Fixed hashcode so that it looks at constructor and arguments.
Hashcode does this by taking 
this.getClass().getName() into account as well.
4988994
@avandeursen avandeursen Fixed hashcode. 95ee51d
@avandeursen avandeursen NAND equality/hashcode/tostring: Tests + fix ee4b15e
@avandeursen avandeursen Tests + fix for Logic.or equality/hashcode/toString. 51ff792
@alexnederlof

Why use getname() in stead of just getClass and let their hashCode() work it out? It's best practice to call hashCode() on other objects when constructing your own hashCode. That way, the responsibility of generating a useful hashcode is left up to the class you are calling.

Member

Good point. Will remove the getName-calls.

@alexnederlof

This is equivalent to return Objects.hashCode(this.getClass().getName(), conditions); right?

Member

No.

Objects.hashCode takes one vararg.
The red old code was OK, in that it 'expanded' the array to individual arguments.

The code you suggest is indeed what I'd want to write (and initially wrote).
However, it does not expand the conditions array to the individual conditions, and hence does a hashcode computation on the array pointer, instead of on the values of the array elements.

@alexnederlof alexnederlof merged commit 572753d into master Jun 11, 2013
@alexnederlof
Member

Very nice!!

@alexnederlof alexnederlof deleted the testing-conditions branch Jun 11, 2013
@alexnederlof
Member

@avandeursen I suspect you didn't use the crawljax eclipse formatter. Could you double check this next time you contribute? Makes the diffs more understandable.

@avandeursen
Member

👍

@amesbah
Member
amesbah commented Jun 11, 2013

Great job!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment