testing HUD

Charles Crouch ccrouch at redhat.com
Mon Aug 22 13:54:04 UTC 2011



----- Original Message -----
> I'll look. Just to be clear, here's what we need to test to ensure we
> really fixed this bug:

The example test I provided has most of these properties and its trivial to enhance...

> 
> 1) Produce identity hash codes for three objects: A, B and C

In the test Integer(1) is given System.hashcode, Integer(2) and Integer(3) are given hashcode of -1

> 2) Ensure that A != B, B != C and A != C

And obviously Integer(1) != Integer(2), Integer(2) != Integer(3) and Integer(1) != Integer(3)

> 
> The purpose of looking at the mocking framework was to avoid having to
> write code whose existence was solely to support testing. 

Agreed. The goal here is to avoid introducing more conditional logic into HibernateDetachUtility
e.g. if (undertest) doThis else doThat, but at the same time to increase testability.
The approach I outlined avoids this and lets the test override the required parts it needs to trigger the scenario we are trying to test for.

> But I'm ok with doing this if the majority is ok with it.
> 
> On 08/21/2011 09:19 AM, Jay Shaughnessy wrote:
> >
> > 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 at lists.fedorahosted.org
> >> https://fedorahosted.org/mailman/listinfo/rhq-devel
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/rhq-devel
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list