This looks in line with what we were saying on the phone, thanks. Mazz
can probably use this as part of his effort. One thing this doesn't do,
and I'm not sure it actually has to do for the purposes of the test, is
to ensure the same indentityHash will be provided when called multiple
times for the same 'value' object. But it may have to because the
specific problem we were looking at was a self-referring situation for
an object suffering identity hash collision.
On 8/21/2011 12:16 AM, Charles Crouch wrote:
Further to the discussion on Friday afternoon around how to test
HibernateDetachUtility, it doesn't seem to need an additional mock testing framework.
I've attached a 17 line patch to HibernateDetachUtility which seems to do the trick of
letting you swap out implementations of hash code generation. Also attached is HDUTest
which is a 23 line (main method) test which at least according to my debugging, once
TestHashCodeGenerator is being used, exercises during its execution all of the different
code paths under:
} else {
// we have a situation where multiple objects have the same identity
hashcode, work with our
// collision map to decide whether it needs to be scrubbed and add if
necessary.
// Note that this code block is infrequently hit, it is by design that
we've pushed the extra
// work, map, etc, involved for this infrequent case into its own block. The
standard cases must
// be as fast and lean as possible.
...
}
Hopefully this could be useful in writing tests to confirm HibernateDetachUtility acts as
we expect it to.
Thanks
Charles
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel