Re: [MO-java-dev] verify()ing object hierachies.

[Jeff M. <je...@mk...>]

Looks reasonable, but could we have a test case for it. It's the sort of
thing that could get broken.

On Fri, 2002-09-13 at 15:23, Simon Levitt wrote:
> On Friday 13 September 2002 11:55, Jeff Martin wrote:
> > It's a general policy to not have mocks manage the relationships with
> > other mocks. The idea is to keep the mocks as simple as possible.
> >
> > This is the reason I've started work on the test helper classes which
> > setup the tree of mocks for you. Though I've not produced any for the
> > JDBC classes as it's more complex than the servlet api.
> >
> I can see this being helpful when there is a collection of objects that 
> need to be associated to sets of each other that have no real defined 
> (single) parent object, but the association of ResultSet to Statement to 
> Connection is a very simple child to single parent relationship. Or am I 
> missing something?
> 
> My changes do the association at usage time (I didn't say that before 
> TBF), in that when a Statement or ResultSet gets returned, it is 
> automatically associated with the Object that you called to get it (I 
> can't see a situation, for JDBC at least, where you would want this any 
> different - or infact has any advantage).
> 
> The set<Parent> interface is still required, as you may have methods to 
> test that take a ResultSet, or Statement, for which the parent object 
> needs manually setting.
> 
> > Don't think this helps if the dependency is more than one level deep.
> [...]
> > Tempted to say forget thread safety (That's not to say it's okay to
> > have static variables.).
> >
> I've got a change (cvs diff -u attached) to Verifier that now at least 
> works for me.
> It has a static Vector (simplest why I could think of) of in verify() 
> objects, and ignores any object already being verified. It also doesn't 
> require any interface change.
> 
> This solves my problem, and unless specific object implementations of 
> verify cause a loop (which was a potential problem anyway), I can't see 
> how this is any worse.
> 
> Simon.,
> -- 
> --------------------------------------------------------------------------
>          Simon Levitt, Senior Development Engineer @ WorldPay plc,
> WorldPay Centre, The Science Park, Milton Rd., Cambridge, CB4 0WE, ENGLAND  
>  Sim...@uk...   Ph:+44(0)1223 715151  F:+44(0)1223 715157
> ------------------------- http://www.worldpay.com/ -----------------------
> ----
> 

> Index: Verifier.java
> ===================================================================
> RCS file: /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects/util/Verifier.java,v
> retrieving revision 1.3
> diff -u -r1.3 Verifier.java
> --- Verifier.java	28 Mar 2002 18:16:54 -0000	1.3
> +++ Verifier.java	13 Sep 2002 13:46:34 -0000
> @@ -3,6 +3,7 @@
>  import com.mockobjects.Verifiable;
>  
>  import java.lang.reflect.Field;
> +import java.util.Vector;
>  
>  /**
>   * Helper class to verify all {@link com.mockobjects.Expectation Expectation}s
> @@ -35,6 +36,8 @@
>   * @version $Id: Verifier.java,v 1.3 2002/03/28 18:16:54 custommonkey Exp $
>   */
>  public class Verifier {
> +
> +    private static Vector myProcessingObjects = new Vector();
>      /**
>       * Public, no-op constructor.
>       * You should not need to instantiate this object, since all methods
> @@ -70,7 +73,7 @@
>       * Recursively verifies all fields of the passed object.
>       * @param anObject The object to be verified.
>       */
> -    static public void verifyObject(Object anObject) {
> +    static synchronized public void verifyObject(Object anObject) {
>          verifyObjectFromClass(anObject, anObject.getClass());
>      }
>  
> @@ -85,15 +88,24 @@
>       * @param aClass The apparent class of <code>anObject</code>
>       */
>      static private void verifyObjectFromClass(Object anObject, Class aClass) {
> +        if (myProcessingObjects.contains(anObject)) {
> +            return;
> +        }
>          if (isRootClass(aClass)) {
>              return;
>          }
>  
>          verifyObjectFromClass(anObject, aClass.getSuperclass());
> -
> -        Field[] fields = aClass.getDeclaredFields();
> -        for (int i = 0; i < fields.length; ++i) {
> -            verifyField(fields[i], anObject);
> +        try {
> +            myProcessingObjects.addElement(anObject);
> +    
> +            Field[] fields = aClass.getDeclaredFields();
> +            for (int i = 0; i < fields.length; ++i) {
> +                verifyField(fields[i], anObject);
> +            }
> +        }
> +        finally {
> +            myProcessingObjects.removeElement(anObject);
>          }
>      }
>  
-- 
jeff martin
information technologist
mkodo limited

mobile: 44 (0) 78 5547 8331
phone: 44 (0) 20 2226 4545
email: je...@mk...

www.mkodo.com