mockobjects-java-dev

[MO-java-dev] Resetting dyna mocks - new reset() method

[Vincent M. <vm...@pi...>]

Hi,

I have a requirement for introducing a reset on dyna mocks so that they
can be reused.

Here's the use case:

I am setting up a Mock InitialContext factory with:

        NamingManager.setInitialContextFactoryBuilder(
            new InitialContextFactoryBuilder() {
                public InitialContextFactory
createInitialContextFactory(
                    Hashtable environment) throws NamingException
                {
                    return new InitialContextFactory() {
                        public Context getInitialContext(Hashtable env) 
                            throws NamingException
                        {
                            // Return the mock context here
                            return context; 
                        }                        
                    };
                }
        });

The setInitialContextFactoryBuilder() is a static method and can only be
called *ONCE* in the lifetime of the JVM. Which means that it will be
shared between testXXX() tests. Thus the InitialContext mock (in "return
context") also has to be static.

The second step is to define expectations on the context mock lookup()
method so that we can return mocks. By doing this we are tying the
static context mock with the other per-testXXX() mocks...

... which means that if we have 2 test methods setting expectations on
lookup() with the same lookup name, the second test fails....

I believe this is a valid use case and that in order to support this use
case, we need to introduce a reset() method in the dynamock Mock class
to rest all expectations.

I've just committed the patch to support this reset method. If you think
we should not have a reset() method, I can always remove it.

Thanks
-Vincent

RE: [MO-java-dev] Resetting dyna mocks - new reset() method

[Tim M. <tim...@po...>]

Vincent - this example makes no sense at all to me? You probably should have
showed the tests that go along with this so we could understand what you are
saying.

This said, I would tentatively advocate a reset - I thing you are mirroring
what Joe said previously in that it can be a pain if you have used setUp to
configure a mock and then later just want to do something totally different
for one case. I have seen this and so would agree with this change.

HOWEVER - YOU ADDED RESET WITHOUT UPDATING THE TESTS!!!! SHAME ON YOU!!!!
Part of the reason for rewriting the mock library was to get better test
coverage...

I would like to get Steve's opinion as well, he is good at enforcing a clean
API. Please can we confer on some of these things to try and prevent a
massive API buildup.

I also want to insist that we don't put comments in the code like you just
did. Please read Martin Fowlers refactoring book -  rather than have:
    /**
     * Resets all expected calls and expected matches.
     */

Call the method something more explicit in the first place, then we you are
using the method in your code, it also won't need a comment above it
either - I would suggest:

  resetAllMatchesAndExpectations.

Then you don't need a comment!

Tim



> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Vincent Massol
> Sent: 17 May 2003 19:55
> To: 'Mockobjects-Java-Dev'
> Subject: [MO-java-dev] Resetting dyna mocks - new reset() method
>
>
> Hi,
>
> I have a requirement for introducing a reset on dyna mocks so that they
> can be reused.
>
> Here's the use case:
>
> I am setting up a Mock InitialContext factory with:
>
>         NamingManager.setInitialContextFactoryBuilder(
>             new InitialContextFactoryBuilder() {
>                 public InitialContextFactory
> createInitialContextFactory(
>                     Hashtable environment) throws NamingException
>                 {
>                     return new InitialContextFactory() {
>                         public Context getInitialContext(Hashtable env)
>                             throws NamingException
>                         {
>                             // Return the mock context here
>                             return context;
>                         }
>                     };
>                 }
>         });
>
> The setInitialContextFactoryBuilder() is a static method and can only be
> called *ONCE* in the lifetime of the JVM. Which means that it will be
> shared between testXXX() tests. Thus the InitialContext mock (in "return
> context") also has to be static.
>
> The second step is to define expectations on the context mock lookup()
> method so that we can return mocks. By doing this we are tying the
> static context mock with the other per-testXXX() mocks...
>
> ... which means that if we have 2 test methods setting expectations on
> lookup() with the same lookup name, the second test fails....
>
> I believe this is a valid use case and that in order to support this use
> case, we need to introduce a reset() method in the dynamock Mock class
> to rest all expectations.
>
> I've just committed the patch to support this reset method. If you think
> we should not have a reset() method, I can always remove it.
>
> Thanks
> -Vincent
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: If flattening out C++ or Java
> code to make your application fit in a relational database is painful,
> don't do it! Check out ObjectStore. Now part of Progress Software.
> http://www.objectstore.net/sourceforge
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003

[MO-java-dev] Is IsEqual testing for equality in the right order?

[<Vin...@ge...>]

Hi,

I noticed that the IsEqual constraint tests for equality by comparing the
expected value against the actual value. IIRC it used to be the other way
around with "static" mocks - i.e. expected.equals(actual) - so you could
deal with legacy code not implementing equals correctly. It has helped me in
a number of situtations. Any reason why this has changed?

Extract from IsEqual :

    public boolean eval( Object arg ) {
    	if(arg instanceof Object[]) {
    		arg = Arrays.asList((Object[])arg);
    	}
        return arg.equals(_object);
    }

It could be _object.equals(arg) or am I missing something?

Thanks,
Vincent

Re: [MO-java-dev] Is IsEqual testing for equality in the right order?

[Nat P. <nat...@b1...>]

According to the Java equals protocol, the expressions arg.equals(_object)
and _object.equals(arg) must act the same, so it makes no difference.  If
the two expressions act differently, then that is a bug in the
implementation of the class of arg or _object.

Cheers,
            Nat.
_______________________
Dr. Nathaniel Pryce
B13media Ltd.
http://www.b13media.com
+44 (0)7712 526 661

----- Original Message -----
From: "Vincent Tence" <Vin...@ge...>
To: "'Mockobjects-Java-Dev'" <moc...@li...>
Sent: Monday, June 02, 2003 10:57 PM
Subject: [MO-java-dev] Is IsEqual testing for equality in the right order?


> Hi,
>
> I noticed that the IsEqual constraint tests for equality by comparing the
> expected value against the actual value. IIRC it used to be the other way
> around with "static" mocks - i.e. expected.equals(actual) - so you could
> deal with legacy code not implementing equals correctly. It has helped me
in
> a number of situtations. Any reason why this has changed?
>
> Extract from IsEqual :
>
>     public boolean eval( Object arg ) {
>     if(arg instanceof Object[]) {
>     arg = Arrays.asList((Object[])arg);
>     }
>         return arg.equals(_object);
>     }
>
> It could be _object.equals(arg) or am I missing something?
>
> Thanks,
> Vincent
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev

RE: [MO-java-dev] Is IsEqual testing for equality in the right order?

[<Vin...@ge...>]

> According to the Java equals protocol, the expressions
> arg.equals(_object)
> and _object.equals(arg) must act the same, so it makes no
> difference.  If
> the two expressions act differently, then that is a bug in the
> implementation of the class of arg or _object.

Thanks, I know that ;-) But sometimes you have to deal with legacy code that
doesn't respect
this contract or doesn't even override equals so the other way around makes
a *big* difference.
It let me override equals in a derived class and use that class as the
expected value in a test,
so that I can overcome the shortcomings of the legacy code.

I can follow your advice and implement my own constraint, but it looks like
the same constraint
to me. If it makes no difference, is it possible to change IsEqual for the
other way around. Unless
it leads to other problems I'm not aware of ...

The ExpectationValue class do it expected.equals(actual) so it's also make
it easier to migrate to the new
dynamic mock framework. Any opinion?

Thanks,
Vincent


> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Nat Pryce
> Sent: Monday, June 02, 2003 6:07 PM
> To: Vincent Tence; 'Mockobjects-Java-Dev'
> Subject: Re: [MO-java-dev] Is IsEqual testing for equality in
> the right
> order?
>
>
> According to the Java equals protocol, the expressions
> arg.equals(_object)
> and _object.equals(arg) must act the same, so it makes no
> difference.  If
> the two expressions act differently, then that is a bug in the
> implementation of the class of arg or _object.
>
> Cheers,
>             Nat.
> _______________________
> Dr. Nathaniel Pryce
> B13media Ltd.
> http://www.b13media.com
> +44 (0)7712 526 661
>
> ----- Original Message -----
> From: "Vincent Tence" <Vin...@ge...>
> To: "'Mockobjects-Java-Dev'"
> <moc...@li...>
> Sent: Monday, June 02, 2003 10:57 PM
> Subject: [MO-java-dev] Is IsEqual testing for equality in the
> right order?
>
>
> > Hi,
> >
> > I noticed that the IsEqual constraint tests for equality by
> comparing the
> > expected value against the actual value. IIRC it used to be
> the other way
> > around with "static" mocks - i.e. expected.equals(actual) -
> so you could
> > deal with legacy code not implementing equals correctly. It
> has helped me
> in
> > a number of situtations. Any reason why this has changed?
> >
> > Extract from IsEqual :
> >
> >     public boolean eval( Object arg ) {
> >     if(arg instanceof Object[]) {
> >     arg = Arrays.asList((Object[])arg);
> >     }
> >         return arg.equals(_object);
> >     }
> >
> > It could be _object.equals(arg) or am I missing something?
> >
> > Thanks,
> > Vincent
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: eBay
> > Get office equipment for less on eBay!
> > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> > _______________________________________________
> > Mockobjects-java-dev mailing list
> > Moc...@li...
> > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>

Re: [MO-java-dev] Is IsEqual testing for equality in the right order?

[Nat P. <nat...@b1...>]

From: "Vincent Tencé" <Vin...@ge...>
> I can follow your advice and implement my own constraint, but it looks
like
> the same constraint
> to me.

In my opinion, if there *is* a difference between a.equals(b) and
b.equals(a) for your objects, then a constraint that takes that into account
is *not* testing equality, but is testing for some broken implementation of
the equals method, and is therefore different from the IsEquals constraint.

Making a new constraint class would make this assumption (that the equals
method is broken) explicit in your tests, which is a good thing.

> The ExpectationValue class do it expected.equals(actual) so it's also make
> it easier to migrate to the new
> dynamic mock framework. Any opinion?

One reason that ExpectationValue implements expected.equals(actual) is so
that tests can create a new class for the expected value that test for
something other than equality in the equals method.  This breaks the equals
protocol and so is (in my opinion) a nasty hack that will bite back at some
time when you least expect it.  The Constraint interface is designed to let
you avoid using this hack by defining exact constraints over method
arguments that do not need to be transitive, symmetrical, etc.

Cheers,
            Nat.

_______________________
Dr. Nathaniel Pryce
B13media Ltd.
http://www.b13media.com
+44 (0)7712 526 661

RE: [MO-java-dev] Is IsEqual testing for equality in the right order?

[<Vin...@ge...>]

I'll try that then. Sometimes I have to deal with legacy objects that don't
override equals and I did not realize at first that the Constraint interface
was there to help. Thanks for the pointer.

Vincent

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Nat Pryce
> Sent: Monday, June 02, 2003 6:42 PM
> To: Vincent Tencé; 'Mockobjects-Java-Dev'
> Subject: Re: [MO-java-dev] Is IsEqual testing for equality in
> the right
> order?
>
>
> From: "Vincent Tencé" <Vin...@ge...>
> > I can follow your advice and implement my own constraint,
> but it looks
> like
> > the same constraint
> > to me.
>
> In my opinion, if there *is* a difference between a.equals(b) and
> b.equals(a) for your objects, then a constraint that takes
> that into account
> is *not* testing equality, but is testing for some broken
> implementation of
> the equals method, and is therefore different from the
> IsEquals constraint.
>
> Making a new constraint class would make this assumption
> (that the equals
> method is broken) explicit in your tests, which is a good thing.
>
> > The ExpectationValue class do it expected.equals(actual) so
> it's also make
> > it easier to migrate to the new
> > dynamic mock framework. Any opinion?
>
> One reason that ExpectationValue implements
> expected.equals(actual) is so
> that tests can create a new class for the expected value that test for
> something other than equality in the equals method.  This
> breaks the equals
> protocol and so is (in my opinion) a nasty hack that will
> bite back at some
> time when you least expect it.  The Constraint interface is
> designed to let
> you avoid using this hack by defining exact constraints over method
> arguments that do not need to be transitive, symmetrical, etc.
>
> Cheers,
>             Nat.
>
> _______________________
> Dr. Nathaniel Pryce
> B13media Ltd.
> http://www.b13media.com
> +44 (0)7712 526 661
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>