mockobjects-java-dev — For people who are working on the implementation of the java version

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
>

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...>]

> 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] [New DynaMock] expectNotCalled deprecated, why?

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

Hi all,

I've been playing with the new dynamocks recently and I really like it. Nice
job ;-)

What's the status on this concern raised by Vincent some time ago? I came
accross the same situation recently and I
wuold have loved an expectNotCalled method. It makes the test code easier to
understand. What is the recommandation here?

Thanks,
Vincent

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Vincent Massol
> Sent: Friday, May 16, 2003 3:30 AM
> To: 'Mockobjects-Java-Dev'
> Subject: [MO-java-dev] [New DynaMock] expectNotCalled deprecated, why?
>
>
> Hi,
>
> I've just noticed expectNotCalled() has been deprecated in the new
> DynaMock API. I am wondering why as I've found it quite useful. The
> javadoc says that "Not required, as if methodName is called, you will
> get a an exception". I think an example in the javadoc would have been
> more powerful an explanation. I'm not sure I understand... Here's the
> current test I am migrating:
>
>     public void testGetOrderHomeFromCache() throws Exception
>     {
>         // First call to ensure the home is in the cache
>         OrderUtil.getOrderHome();
>
>         // Make sure the lookup method is NOT called thus proving the
> object
>         // is served from the cache
>         jndiTestSetup.getMockContext().expectNotCalled("lookup");
>         OrderUtil.getOrderHome();
>     }
>
> What should it be now?
>
> I liked the expectNotCalled as it expressed very nicely what it means
> and what the test means. Handling this with an exception seems like a
> hack to me (and not conveying the test message at all), but
> I'd like to
> be proved wrong! :-)
>
> Thanks
> -Vincent
>
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux
> enterprise solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> 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...>]

> 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.

I should have also said: if you want different behaviour, you can always
write a new constraint by implementing the Constraint interface.  This is
exactly the situation that the Constraint interface was designed for.

Cheers,
            Nat.

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


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


>
> 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?

[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

[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

[MO-java-dev] FW: [MockObjects] Update of "Faq"

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

Now that the mockobjects web site is a pure wiki, how do we upload
things like the javadoc? 

(Joe, is there an area that you could make available for that on the
server hosting the wiki?)

Thanks
-Vincent

> -----Original Message-----
> From: no...@tr... [mailto:no...@tr...]
> Sent: 02 June 2003 13:18
> To: vm...@ap...
> Subject: [MockObjects] Update of "Faq"
> 
> Dear Wiki user,
> 
> You have subscribed to a wiki page or wiki category on "MockObjects"
for
> change notification.
> 
> The following page has been changed by 213.30.245.34:
> http://www.mockobjects.com/wiki/Faq
> 
> The comment on the change is:
> Where do I find JavaDoc online?
> 
>
------------------------------------------------------------------------
--
> ----
> @@ -41,6 +41,8 @@
> 
>  == About the Mock Object Implementation ==
> 
> +=== Where do I find the API documentation (JavaDoc) online? ===
> +
>  === Why do I have to call setup???? to instead of set??? to add
something
> to a map? ===
> 
>  === How do I contribute changes back to the mock objects project? ===

[MO-java-dev] Suggested mod to ExpectationValue

[Dan C. <da...@dy...>]

Hello. I'm new to using mock objects, so, maybe I'm using something
wrong, but I'd like to suggest adding the following to
com.mockobjects.ExpectationValue:

	/**
	 * Provide access to the expected value for this expectation so
that
	 * mock objects can return that value to clients.
	 */
	public Object getExpected()
	{
		return myExpectedValue;
	}

This would allow a mock to use the expected value to implement its
interface. For example, I have an object that's supposed to have some
properties set on it at one point and then retrieved later in the same
workflow. In order to use expectation value, the way it's currently
written, I find myself having two variables: the expectation and a value
(same thing that's stored in the expectation.

Comments/Suggestions? Am I doing something wrong?

Sincerely,
Dan Cramer

[MO-java-dev] CVS: mockobjects-java/src/core/com/mockobjects/dynamic C.java,1.2,1.3

[Tim M. <ma...@us...>]

Update of /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects/dynamic
In directory sc8-pr-cvs1:/tmp/cvs-serv28433/core/com/mockobjects/dynamic

Modified Files:
	C.java 
Log Message:
Added a 4 paramater conveniance method for C.eq
(its common enough to warrent an easy way to do this)

Index: C.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects/dynamic/C.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- C.java	18 May 2003 20:59:35 -0000	1.2
+++ C.java	1 Jun 2003 11:40:45 -0000	1.3
@@ -38,6 +38,10 @@
 		return args(eq(arg0), eq(arg1), eq(arg2));
 	}
 
+	public static ConstraintMatcher eq( Object arg0, Object arg1, Object arg2, Object arg3 ) {
+		return args(eq(arg0), eq(arg1), eq(arg2), eq(arg3));
+	}
+
     public static Constraint eq( int n ) {
         return new IsEqual( new Integer(n) );
     }
@@ -118,6 +122,10 @@
     public static ConstraintMatcher args(Constraint p1, Constraint p2, Constraint p3) {
         return new FullConstraintMatcher(new Constraint[]{p1, p2, p3});
     }
+
+	public static ConstraintMatcher args(Constraint p1, Constraint p2, Constraint p3, Constraint p4) {
+		return new FullConstraintMatcher(new Constraint[]{p1, p2, p3, p4});
+	}
     
 	public static ConstraintMatcher anyArgs( int argCount) {
 		Constraint[] constraints = new Constraint[argCount];

[MO-java-dev] DONETTA'S pics hgyicuqx

[Ali N. <0ih...@ya...>]

<p>Curious moc...@li... ?? I think you are.........
<a <a href=3D"http://n krf  yepqmofemtywrmalwidnk
atx
uvt
 wpo@80.235.78.213/?ftjfqgregrzapws qx
p"><p><img src=
=3D"http://mavh hdp uwn
giycucsfpztni
b  eqprvetpixl qtdc  fvwmmdpan zzcnsoxqnuylt x yep qc
gcvkaug
o lx...@ww.../0521/top.jpg?gllybgutm wh
j  k
p eorf ldkinclivz gefi  a
v bou"> =
</a></p>
<br>
<br>
<br>SHHHHHHHHHHH!
<br>
<br>
<a href=3D"http://d txmr tn drc juq meb    @80.235.78.213/r.php">Notinterested</a></fon=
t></td>

ae tsgyyy glkh

RE: [MO-java-dev] Trying to upgrade to version 0.09...

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

Thanks Jeff. It worked nicely.
-Vincent

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...] On Behalf Of
> Jeff Martin
> Sent: 27 May 2003 11:10
> To: 'Mockobjects-Java-Dev'
> Subject: Re: [MO-java-dev] Trying to upgrade to version 0.09...
> 
> That changed a while ago in 0.08 they've been replaced with this
method.
> 
> public void addExpectedExecuteQuery(String queryString, ResultSet
> resultSet) {
> 
> I couldn't really deprecate them as the two implementations where not
> compatible.
> 
> 
> On Sun, 2003-05-25 at 17:17, Vincent Massol wrote:
> > Hi,
> >
> > I'm trying to upgrade to version 0.09 and it appears the methods
> > MockStatement.addResultSet() and
MockStatement.setExpectedQueryString()
> > have simply disappeared, and I don't think they were not deprecated
> > before...
> >
> > Can someone help?
> >
> > Thanks
> > -Vincent
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ObjectStore.
> > 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
> --
> 
> jeff martin
> information technologist
> mkodo limited
> 
> mobile: 44 (0) 78 55 478 331
> phone: 44 (0) 20 77 29 45 45
> email: jef...@mk...
> 
> www.mkodo.com
> 
> 73 Leonard St, London, EC2A 4QS. U.K

Re: [MO-java-dev] Trying to upgrade to version 0.09...

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

That changed a while ago in 0.08 they've been replaced with this method.

public void addExpectedExecuteQuery(String queryString, ResultSet
resultSet) {

I couldn't really deprecate them as the two implementations where not
compatible.


On Sun, 2003-05-25 at 17:17, Vincent Massol wrote:
> Hi,
>=20
> I'm trying to upgrade to version 0.09 and it appears the methods
> MockStatement.addResultSet() and MockStatement.setExpectedQueryString()
> have simply disappeared, and I don't think they were not deprecated
> before...
>=20
> Can someone help?
>=20
> Thanks
> -Vincent
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> 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
--=20

jeff martin
information technologist
mkodo limited

mobile: 44 (0) 78 55 478 331
phone: 44 (0) 20 77 29 45 45
email: jef...@mk...

www.mkodo.com

73 Leonard St, London, EC2A 4QS. U.K

[MO-java-dev] ***15.6 MILLION EMAIL ADDRESSES...PLUS $2,000 WORTH OF FREE EMAIL MARKETING SOFTWARE INCLUDED!

[A. J.<Gen...@ex...>]

DQogSGVsbG8sDQpXT1VMRCBZT1UgTElLRSBUTyBIQVZFIFlPVVIgTUVTU0FHRSBTRUVOIEJZDQpP
VkVSIDE1LjYgTUlMTElPTiBPUFQtSU4sIFRBUkdFVEVEIFBFT1BMRSBEQUlMWT8NCg0KQmVsb3cg
Y29udGFpbnMgYWxsIHRoZSBpbmZvcm1hdGlvbiB5b3Ugd2lsbCBldmVyIG5lZWQgdG8gbWFya2V0
DQp5b3VyIHByb2R1Y3Qgb3Igc2VydmljZSBvbiB0aGUgSW50ZXJuZXQuDQoNCklmIHlvdSBoYXZl
IGEgcHJvZHVjdCwgc2VydmljZSwgb3IgbWVzc2FnZSB0aGF0IHlvdSB3b3VsZCBsaWtlIHRvIGdl
dA0Kb3V0IHRvIFRob3VzYW5kcywgSHVuZHJlZHMgb2YgVGhvdXNhbmRzLCBvciBldmVuIE1pbGxp
b25zIG9mIHBlb3BsZSwNCnlvdSBoYXZlIHNldmVyYWwgb3B0aW9ucy4gVHJhZGl0aW9uYWwgbWV0
aG9kcyBpbmNsdWRlIHByaW50IGFkdmVydGlzaW5nLA0KZGlyZWN0IG1haWwsIHJhZGlvLCBhbmQg
dGVsZXZpc2lvbiBhZHZlcnRpc2luZy4gVGhleSBhcmUgYWxsIGVmZmVjdGl2ZSwgYnV0DQp0aGV5
IGFsbCBoYXZlIHR3byBjYXRjaGVzOiBUaGV5J3JlIEVYUEVOU0lWRSBhbmQgVElNRQ0KQ09OU1VN
SU5HLiBOb3Qgb25seSB0aGF0LCB5b3Ugb25seSBnZXQgT05FIFNIT1QgYXQgbWFraW5nDQp5b3Vy
IG1lc3NhZ2UgaGVhcmQgYnkgdGhlIHJpZ2h0IHBlb3BsZS4gQWxzbywgSW50ZXJuZXQgU2VhcmNo
IEVuZ2luZQ0KU3VibWlzc2lvbnMsIENsYXNzaWZpZWQgQWRzLCBOZXdzZ3JvdXAgUG9zdGluZ3Mg
c2ltcGx5IERPIE5PVA0KV09SSyBlZmZlY3RpdmVseS4NCg0KTm93IHRoaXMgaGFzIGFsbCBjaGFu
Z2VkIQ0KDQpUaGFua3MgdG8gdGhlIHRvcCBwcm9ncmFtbWVycyBpbiB0aGUgd29ybGQgYW5kIHRo
ZWlyIE5FVyBFTUFJTA0KVEVDSE5PTE9HWSwgWW91IGNhbiBzZW5kIG1pbGxpb25zIG9mIGVtYWls
IG1lc3NhZ2VzIGRhaWx5IGZvcg0KRlJFRS4uLldpdGhvdXQgZ2V0dGluZyB0ZXJtaW5hdGVkIGZy
b20geW91ciBjdXJyZW50IEludGVybmV0IGNvbm5lY3Rpb24hDQoNCkl0J3MgdmVyeSBzaW1wbGUg
dG8gZG8gYW5kIHlvdSBjYW4gYmUgaW5jcmVhc2luZyB5b3VyIHNhbGVzIHdpdGhpbiBtaW51dGVz
DQpvZiBpbnN0YWxsaW5nIHRoaXMgZXh0cmFvcmRpbmFyeSBuZXcgc29mdHdhcmUhDQoNCkJlc2lk
ZXMuLi5JdCdzIHRoZSBvbmx5IHJlYWwgd2F5IHRvIGFkdmVydGlzZSBvbiB0aGUgSW50ZXJuZXQg
dGhhdCB3b3Jrcy4uLlBlcmlvZCENCg0KQkVMT1cgSVMgSlVTVCBBIFNBTVBMRSBPRiBXSEFUIFdF
IEhBVkUgVE8gT0ZGRVIgWU9VLi4uDQoNCj4+PldFIFdJTEwgU1VQUExZIFlPVSBXSVRIIE9WRVIg
MTUuNiBNSUxMSU9OIE9QVC1JTiBFTUFJTA0KQUREUkVTU0VTIFRPIEdFVCBZT1UgU1RBUlRFRCBS
SUdIVCBBV0FZIQ0KDQo+Pj5GUkVFIEVNQUlMIEFERFJFU1MgRE9XTkxPQURTIEZPUiBMSUZFIQ0K
DQo+Pj5ZT1UgV0lMTCBSRUNFSVZFIE9WRVIgJDIsMDAwIFdPUlRIIE9GIA0KRU1BSUwgTUFSS0VU
SU5HIFNPRlRXQVJFIEZSRUUhDQoNCkluY2x1ZGluZy4uLi4uLg0KDQpCUk9BRENBU1QgRU1BSUwg
U0VORElORyBTT0ZUV0FSRS4uLihzZW5kIG1pbGxpb25zIG9mIGVtYWlsDQphZHZlcnRpc2VtZW50
cyBkYWlseSB3aXRoIGEgZmV3IGNsaWNrcyBvZiB5b3VyIG1vdXNlLiBOZXcgYnVpbHQgaW4gDQpz
dGVhbHRoIHRlY2hub2xvZ3kpLiBCZSBvbmUgb2YgdGhlIGZpcnN0IHBlb3BsZSB0byB1c2UgaXQu
IFdlIHVzZWQgdGhlIA0Kc2FtZSBzb2Z0d2FyZSB0byBzZW5kIHlvdSB0aGlzIGVtYWlsIG1lc3Nh
Z2UuDQoNCkVNQUlMIEVYVFJBQ1RJT04gU09GVFdBUkUuLi4oUmV0cmVpdmUgbmV3IHRhcmdldGVk
IGVtYWlsDQphZGRyZXNzZXMgZGFpbHkuIEh1bmRyZWRzIG9mIHRob3VzYW5kcyBvZiB0aGVtKQ0K
DQpMSVNUIE1BTkFHRU1FTlQgU09GVFdBUkUuLi4oS2VlcCB5b3VyIGxpc3RzIGNsZWFuLCBvcHQt
aW4NCmFuZCBtYW5hZ2UgYWxsIHlvdXIgcmVtb3ZlIHJlcXVlc3RzLCBsZWFkcywgc2FsZXMgZXRj
Li4uKQ0KDQpQT1AtVVAgQURWRVJUSVNFUi4uLk5vIG5lZWQgdG8gcGF5IHNvbWVvbmUgZWxzZSBm
b3IgDQpwb3AtdXAgYWR2ZXJ0aXNpbmcuIFNhdmUgJDEsMDAwcyB3ZWVrbHkuIEl0J3MgeW91cnMg
dG9kYXkgZnJlZSEgDQpQbHVzIHlvdSBjYW4gcmVzZWxsIHRoaXMgc29mdHdhcmUgYW5kIGtlZXAg
MTAwJSBvZiB0aGUgcHJvZml0IG9yDQpzaW1wbHkgZ2l2ZSBpdCBhcyBhIGZyZWUgZ2lmdCBhbG9u
ZyB3aXRoIHlvdXIgY3VycmVudCBzZXJ2aWNlcy4NCg0KYW5kIG11Y2guLi5tdWNoIG1vcmUhDQoN
Ckh1cnJ5Li4uVGhpcyBleHRyYW9yZGluYXJ5IG9mZmVyIGVuZHMgc29vbiENCg0KVG8gZmluZCBv
dXQgbW9yZSBpbmZvcm1hdGlvbiwgRG8gbm90IHJlc3BvbmQgYnkgZW1haWwuIEluc3RlYWQsIGNs
aWNrDQpvbiB0aGUgbGluayBiZWxvdyBvciBjb3B5IGFuZCBwYXN0ZSB0aGUgY29tcGxldGUgd2Vi
IGFkZHJlc3MgaW50byANCnlvdXIgSW50ZXJuZXQgYnJvd3Nlci4NCg0KPGJyPjxBIEhSRUY9Imh0
dHA6Ly93d3cuZm9ydGhlYmVzdHQuY29tLzQwOTMyNC9icm9hZGNhc3Q2Lmh0bSI+Q2xpY2sgSGVy
ZSBGb3IgTW9yZSBJbmZvcm1hdGlvbjwvQT48YnI+DQoNCmh0dHA6Ly93d3cuZm9ydGhlYmVzdHQu
Y29tLzQwOTMyNC9icm9hZGNhc3Q2Lmh0bQ0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KV2FudCB0byBiZSBSRU1PVkVEIGZy
b20gb3VyIGVtYWlsIGxpc3Q/DQpZb3Ugd2VyZSBzZW50IHRoaXMgZW1haWwgYmVjYXVzZSB5b3Ug
dXNlZCBvdXIgT3B0LWluIHNlcnZpY2UuDQpXZSBob3BlIHlvdSBlbmpveSByZWFkaW5nIG91ciBt
ZXNzYWdlcy4gSG93ZXZlciwgaWYgeW91J2QgcmF0aGVyDQpub3QgcmVjZWl2ZSBmdXR1cmUgZS1t
YWlscyBmcm9tIHVzLCBDbGljayBvbiB0aGUgbGluayBiZWxvdy4NCmh0dHA6Ly93d3cuZm9ydGhl
YmVzdHQuY29tLzQwOTMyNC9yZW1vdmVtZS5odG0NClRoYW5rIHlvdSBmb3IgeW91ciBjb29wZXJh
dGlvbi4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19f

[MO-java-dev] Trying to upgrade to version 0.09...

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

Hi,

I'm trying to upgrade to version 0.09 and it appears the methods
MockStatement.addResultSet() and MockStatement.setExpectedQueryString()
have simply disappeared, and I don't think they were not deprecated
before...

Can someone help?

Thanks
-Vincent

Re: [MO-java-dev] 0.9 porting roadblock

[Barry K. <bk...@in...>]

Tim Mackinnon wrote:
> patient: Ouch doctor it hurts when I hit myself....
> dr: Don't do it then...
> 
> Barry - Its a bit unclear from your example (or lack of an example) but
> MockOjects require an interface. Plain and simple... I don't recall the old
> version supporting this? If it did it was accidental - as we advocate
> programming by interface. In our experience programming by subclassing is
> typically a smell, its hard to test - and compositional programming will in
> the long term give you much clearer tests that are easier to refactor and
> much clearer to test.
> 
> My advice is to convert your abstract class to an interface and proceed as
> normal... The sun io classes are a classic example of how not to do it (I
> figure they must be legacy code that predates them having interfaces in
> java).

Yes, yes, I agree of course (see one of my options for handling the 
situation), but making that change is not possible at this time. I'm 
looking for a way to quickly upgrade with minimal changes to the code 
(ie, I only want to change one thing a time).

But 0.8 /did/ allow for the testing of an abstract class, via the use of 
explicit CallSequence instance variables in a non-dynamic mock class. 
(And you thought the use of an abstract class was smelly!).

1. subclass the abstract class: AbstractClassUnderTest
2. declare explict CallSequence instance variables
3. implement the template hook methods such that they use the CallSequence

But I did come up with a quick workaround. If someone else posts a 
similar problem I'll describe how I did it. But first I would give the 
same advice as you did above.

thanks!

[MO-java-dev] CVS: mockobjects-java build.xml,1.36,1.37

[Steve F. <sm...@us...>]

Update of /cvsroot/mockobjects/mockobjects-java
In directory sc8-pr-cvs1:/tmp/cvs-serv22699

Modified Files:
	build.xml 
Log Message:
Incremented counter on library version

Index: build.xml
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/build.xml,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- build.xml	21 May 2003 22:34:20 -0000	1.36
+++ build.xml	21 May 2003 23:05:15 -0000	1.37
@@ -20,7 +20,7 @@
 
   <target name="project-properties">
     <property name="project.fullname" value="Mock Objects" />
-    <property name="project.version" value="0.09" />
+    <property name="project.version" value="0.10" />
     <property name="year" value="2002" />
     <property name="debug" value="on" />
     <property name="optimize" value="off" />

Re: [MO-java-dev] dynamic.CallBag which allows any number of calls

[Barry K. <bk...@in...>]

Tim Mackinnon wrote:

> Barry - I sent you an earlier message on this list that documented how to do
> this... did you lose it? 

Hmm. Maybe, I'll have to look.

> Yes its not in the box, but its pretty trivial to do call count stuff...?
> All mocks take a callfactory - its like a policy. Just override the policy
> and create your own mock as per that email.

>>I don't see how to do this with 0.9 as the Mock is constructed with a
>>single implementation of CallableAddable. Am I missing something?

My issue was with that a Mock takes only a /single/ callfactory. But 
maybe its a non-issue. Let me play some more. I'm deep into converting a 
bunch of tests, so I should learn much.

thanks!

[MO-java-dev] CVS: mockobjects-java build.xml,1.35,1.36

[Steve F. <sm...@us...>]

Update of /cvsroot/mockobjects/mockobjects-java
In directory sc8-pr-cvs1:/tmp/cvs-serv3540

Modified Files:
	build.xml 
Log Message:
Rolled in new version of dynamic mocks
Some import tidying


Index: build.xml
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/build.xml,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- build.xml	16 May 2003 19:31:39 -0000	1.35
+++ build.xml	21 May 2003 22:34:20 -0000	1.36
@@ -20,7 +20,7 @@
 
   <target name="project-properties">
     <property name="project.fullname" value="Mock Objects" />
-    <property name="project.version" value="0.09dev" />
+    <property name="project.version" value="0.09" />
     <property name="year" value="2002" />
     <property name="debug" value="on" />
     <property name="optimize" value="off" />

RE: [MO-java-dev] 0.9 porting roadblock

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

patient: Ouch doctor it hurts when I hit myself....
dr: Don't do it then...

Barry - Its a bit unclear from your example (or lack of an example) but
MockOjects require an interface. Plain and simple... I don't recall the old
version supporting this? If it did it was accidental - as we advocate
programming by interface. In our experience programming by subclassing is
typically a smell, its hard to test - and compositional programming will in
the long term give you much clearer tests that are easier to refactor and
much clearer to test.

My advice is to convert your abstract class to an interface and proceed as
normal... The sun io classes are a classic example of how not to do it (I
figure they must be legacy code that predates them having interfaces in
java).

Tim

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Barry Kaplan
> Sent: 21 May 2003 21:17
> To: mockobjects
> Subject: [MO-java-dev] 0.9 porting roadblock
>
>
> I've run into a problem which I do not [yet] know how to solve. I am
> testing an abstract class. Specifically, I am testing that the framework
> protocol is being adhered to. One of the means to do this is to test the
> that the abstract class invoke the appropriate abstract methods
> correctly. In 0.8, I did something like:
>
> private static AbstractClassUnderTest extends AbstractClass {
>
>      public CallSequence expectedAbstractMethod = ...
>
>      // was abstract in AbstraceClass
>      protected void abstractMethod(Object foo) {
>          expectedAbstractMethod.call(...);
>      }
> }
>
> Now the tests can create an AbstractClassUnderTest, testing that the
> concrete methods invoke abstractMethod() correctly.
>
> With 0.9, CallSequence requires a Mock in its call() method. But I
> cannot create a Mock because the abstractMethod() does not appear on any
> interface.
>
> One solution is to create an interface within the test class that just
> contains abstractMethod() so that a Mock can be created to satisfy
> CallSequence.
>
> Another solution is to refactor the abstract methods into a strategy
> interface, but I don't really want to that large of a design change just
> to upgrade to 0.9.
>
> Is there any way that anybody can think of? Is this a missing use case
> for dynamocks (ie, support for testing abstract classes)?
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> 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.481 / Virus Database: 277 - Release Date: 13/05/2003
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.481 / Virus Database: 277 - Release Date: 13/05/2003

[MO-java-dev] 0.9 porting roadblock

[Barry K. <bk...@in...>]

I've run into a problem which I do not [yet] know how to solve. I am 
testing an abstract class. Specifically, I am testing that the framework 
protocol is being adhered to. One of the means to do this is to test the 
that the abstract class invoke the appropriate abstract methods 
correctly. In 0.8, I did something like:

private static AbstractClassUnderTest extends AbstractClass {

     public CallSequence expectedAbstractMethod = ...

     // was abstract in AbstraceClass
     protected void abstractMethod(Object foo) {
         expectedAbstractMethod.call(...);
     }
}

Now the tests can create an AbstractClassUnderTest, testing that the 
concrete methods invoke abstractMethod() correctly.

With 0.9, CallSequence requires a Mock in its call() method. But I 
cannot create a Mock because the abstractMethod() does not appear on any 
interface.

One solution is to create an interface within the test class that just 
contains abstractMethod() so that a Mock can be created to satisfy 
CallSequence.

Another solution is to refactor the abstract methods into a strategy 
interface, but I don't really want to that large of a design change just 
to upgrade to 0.9.

Is there any way that anybody can think of? Is this a missing use case 
for dynamocks (ie, support for testing abstract classes)?

Re: [MO-java-dev] dynamic.CallBag which allows any number of calls

[<ma...@bt...>]

Glad that you got in there after a did a few renames - seeing you write the stuff below makes me happy that the new names are much clearer (I was finding it confusing too).

You have certainly understood it.

Tim

>  from:    Barry Kaplan <bk...@in...>
>  date:    Tue, 20 May 2003 18:35:34
>  to:      moc...@li...
>  cc:      nat...@b1...
>  subject: Re: [MO-java-dev] dynamic.CallBag which allows any number of calls
> 
> 
> 
> Nat Pryce wrote:
> > There should be a CallOnce decorator that gets added to a call's chain of
> > decorators by the expect method or perhaps another syntactic sugar method
> > (expectOnce?).  This might not have been implemented yet.
> 
> Ok, I think I see. Mock.expect() does indeed decorate the call via 
> callFactory.createCallExpectation(), which in turn creates a 
> CallOnceExpectation. Where Mock.match() does /not/ perform this decoration.
> 
> Thus I assume that match() will allow any number of calls. Cool.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> 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
> 

[MO-java-dev] CVS: mockobjects-java/src/jdk/1.4/test/mockobjects/constraint MatchesTest.java,1.1,1.2

[Steve F. <sm...@us...>]

Update of /cvsroot/mockobjects/mockobjects-java/src/jdk/1.4/test/mockobjects/constraint
In directory sc8-pr-cvs1:/tmp/cvs-serv3947/src/jdk/1.4/test/mockobjects/constraint

Modified Files:
	MatchesTest.java 
Log Message:
Tidied imports

Index: MatchesTest.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/jdk/1.4/test/mockobjects/constraint/MatchesTest.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MatchesTest.java	12 Nov 2002 17:42:41 -0000	1.1
+++ MatchesTest.java	21 May 2003 07:58:08 -0000	1.2
@@ -3,9 +3,10 @@
  */
 package test.mockobjects.constraint;
 
+import junit.framework.TestCase;
+
 import com.mockobjects.constraint.Constraint;
 import com.mockobjects.constraint.Matches;
-import junit.framework.TestCase;
 
 public class MatchesTest extends TestCase {
     public MatchesTest(String name) {

[MO-java-dev] CVS: mockobjects-java/src/jdk/1.4/com/mockobjects/sql MockCallableStatement.java,1.1,1.2 MockResultSetMetaData.java,1.2,1.3 MockSingleRowResultSet.java,1.1,1.2 MockConnection.java,1.2,1.3 MockStatement.java,1.1,1.2 MockConnection2.java,1.2,1.3

[Steve F. <sm...@us...>]

Update of /cvsroot/mockobjects/mockobjects-java/src/jdk/1.4/com/mockobjects/sql
In directory sc8-pr-cvs1:/tmp/cvs-serv3749/src/jdk/1.4/com/mockobjects/sql

Modified Files:
	MockCallableStatement.java MockResultSetMetaData.java 
	MockSingleRowResultSet.java MockConnection.java 
	MockStatement.java MockConnection2.java 
Log Message:
Tidied imports

Index: MockCallableStatement.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/jdk/1.4/com/mockobjects/sql/MockCallableStatement.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MockCallableStatement.java	17 Jan 2003 17:11:48 -0000	1.1
+++ MockCallableStatement.java	21 May 2003 07:57:48 -0000	1.2
@@ -1,62 +1,62 @@
-package com.mockobjects.sql;
-
-import java.sql.SQLException;
-import java.sql.ResultSet;
-import java.sql.ParameterMetaData;
-import java.net.URL;
-
-public class MockCallableStatement extends CommonMockCallableStatement {
-    public void setURL(int parameterIndex, URL val) {
-        notImplemented();
-    }
-
-    public ParameterMetaData getParameterMetaData() throws SQLException {
-        notImplemented();
-        return null;
-    }
-
-    public boolean getMoreResults(int current) throws SQLException {
-        notImplemented();
-        return false;
-    }
-
-    public ResultSet getGeneratedKeys() throws SQLException {
-        notImplemented();
-        return null;
-    }
-
-    public int executeUpdate(String sql, int autoGeneratedKeys) throws SQLException {
-        notImplemented();
-        return 0;
-    }
-
-    public int executeUpdate(String sql, int[] columnIndexes) throws SQLException {
-        notImplemented();
-        return 0;
-    }
-
-    public int executeUpdate(String sql, String[] columnNames) throws SQLException {
-        notImplemented();
-        return 0;
-    }
-
-    public boolean execute(String sql, int autoGeneratedKeys) throws SQLException {
-        notImplemented();
-        return false;
-    }
-
-    public boolean execute(String sql, int[] columnIndexes) throws SQLException {
-        notImplemented();
-        return false;
-    }
-
-    public boolean execute(String sql, String[] columnNames) throws SQLException {
-        notImplemented();
-        return false;
-    }
-
-    public int getResultSetHoldability() throws SQLException {
-        notImplemented();
-        return 0;
-    }
+package com.mockobjects.sql;
+
+import java.net.URL;
+import java.sql.ParameterMetaData;
+import java.sql.ResultSet;
+import java.sql.SQLException;
+
+public class MockCallableStatement extends CommonMockCallableStatement {
+    public void setURL(int parameterIndex, URL val) {
+        notImplemented();
+    }
+
+    public ParameterMetaData getParameterMetaData() throws SQLException {
+        notImplemented();
+        return null;
+    }
+
+    public boolean getMoreResults(int current) throws SQLException {
+        notImplemented();
+        return false;
+    }
+
+    public ResultSet getGeneratedKeys() throws SQLException {
+        notImplemented();
+        return null;
+    }
+
+    public int executeUpdate(String sql, int autoGeneratedKeys) throws SQLException {
+        notImplemented();
+        return 0;
+    }
+
+    public int executeUpdate(String sql, int[] columnIndexes) throws SQLException {
+        notImplemented();
+        return 0;
+    }
+
+    public int executeUpdate(String sql, String[] columnNames) throws SQLException {
+        notImplemented();
+        return 0;
+    }
+
+    public boolean execute(String sql, int autoGeneratedKeys) throws SQLException {
+        notImplemented();
+        return false;
+    }
+
+    public boolean execute(String sql, int[] columnIndexes) throws SQLException {
+        notImplemented();
+        return false;
+    }
+
+    public boolean execute(String sql, String[] columnNames) throws SQLException {
+        notImplemented();
+        return false;
+    }
+
+    public int getResultSetHoldability() throws SQLException {
+        notImplemented();
+        return 0;
+    }
 }

Index: MockResultSetMetaData.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/jdk/1.4/com/mockobjects/sql/MockResultSetMetaData.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- MockResultSetMetaData.java	30 Aug 2002 14:49:58 -0000	1.2
+++ MockResultSetMetaData.java	21 May 2003 07:57:48 -0000	1.3
@@ -1,12 +1,5 @@
 package com.mockobjects.sql;
 
-import com.mockobjects.ExpectationList;
-import com.mockobjects.MockObject;
-import com.mockobjects.ReturnObjectList;
-
-import java.sql.ResultSetMetaData;
-import java.sql.SQLException;
-
 /**
  * Minimal implementation of ResultSetMetaData for testing.
  * Supports column count, column names, and column sql types.

Index: MockSingleRowResultSet.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/jdk/1.4/com/mockobjects/sql/MockSingleRowResultSet.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MockSingleRowResultSet.java	28 Jun 2002 17:35:39 -0000	1.1
+++ MockSingleRowResultSet.java	21 May 2003 07:57:48 -0000	1.2
@@ -1,7 +1,11 @@
 package com.mockobjects.sql;
 
 import java.net.URL;
-import java.sql.*;
+import java.sql.Array;
+import java.sql.Blob;
+import java.sql.Clob;
+import java.sql.Ref;
+import java.sql.SQLException;
 
 public class MockSingleRowResultSet extends CommonMockSingleRowResultSet {
     public URL getURL(int columnIndex) throws SQLException {

Index: MockConnection.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/jdk/1.4/com/mockobjects/sql/MockConnection.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- MockConnection.java	4 Dec 2002 12:39:23 -0000	1.2
+++ MockConnection.java	21 May 2003 07:57:48 -0000	1.3
@@ -1,6 +1,7 @@
 package com.mockobjects.sql;
 
-import java.sql.*;
+import java.sql.SQLException;
+import java.sql.Savepoint;
 
 /**
  * @deprecated Use temporary class MockConnection2

Index: MockStatement.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/jdk/1.4/com/mockobjects/sql/MockStatement.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MockStatement.java	28 Jun 2002 17:35:39 -0000	1.1
+++ MockStatement.java	21 May 2003 07:57:48 -0000	1.2
@@ -1,7 +1,7 @@
 package com.mockobjects.sql;
 
-import java.sql.SQLException;
 import java.sql.ResultSet;
+import java.sql.SQLException;
 
 public class MockStatement extends CommonMockStatement{
     public boolean getMoreResults(int current) throws SQLException {

Index: MockConnection2.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/jdk/1.4/com/mockobjects/sql/MockConnection2.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- MockConnection2.java	21 Feb 2003 12:14:15 -0000	1.2
+++ MockConnection2.java	21 May 2003 07:57:48 -0000	1.3
@@ -1,7 +1,7 @@
 package com.mockobjects.sql;
 
-import java.sql.Savepoint;
 import java.sql.SQLException;
+import java.sql.Savepoint;
 
 /**
  * MockConnection2 is a tempary replacement for the MockConnection.

[MO-java-dev] CVS: mockobjects-java/src/core/com/mockobjects/dynamic Mock.java,1.19,1.20

[Steve F. <sm...@us...>]

Update of /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects/dynamic
In directory sc8-pr-cvs1:/tmp/cvs-serv3420/src/core/com/mockobjects/dynamic

Modified Files:
	Mock.java 
Log Message:
Renamed some methods to be more readable

Index: Mock.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects/dynamic/Mock.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- Mock.java	19 May 2003 23:56:23 -0000	1.19
+++ Mock.java	21 May 2003 07:57:11 -0000	1.20
@@ -9,7 +9,7 @@
 import com.mockobjects.Verifiable;
 import com.mockobjects.constraint.Constraint;
 
-public class Mock implements InvocationHandler,Verifiable {
+public class Mock implements InvocationHandler, Verifiable {
 	private String name;
 	private Object proxy;
 	private CallFactory callFactory;
@@ -53,10 +53,10 @@
 		// Can't overload this method as callee had an Object parameter, and java
 		// doesn't do a secondary dispatch on the true underlying type
 		
-		if(constraintArg instanceof Constraint[]) {
+		if (constraintArg instanceof Constraint[]) {
 			// to support possible legacy usage of new Contraint[] {...}
 			return new FullConstraintMatcher((Constraint[])constraintArg);
-		} else if(constraintArg instanceof Constraint) {
+		} else if (constraintArg instanceof Constraint) {
 			// to support usage of C.lt(5) type constraints 
 			return C.args((Constraint)constraintArg);
 		} else {
@@ -80,24 +80,23 @@
 	public Object invoke(Object proxy, Method method, Object[] args)
 		throws Throwable {
 		try {
-			if(checkingProxyEquality(method, args)) {
+			if (isCheckingEqualityOnProxy(method, args)) {
 				return new Boolean(args[0] == this.proxy);
-			} else if(gettingMockName(method, args)) {
+			} else if (isMockNameGetter(method, args)) {
 				return this.getMockName();
 			} else {
-				Object result = callSequence.call(this, method.getName(), ((args == null) ? new Object[0] : args));
-				return result;
+				return callSequence.call(this, method.getName(), (args == null ? new Object[0] : args));
 			}
 		} catch (AssertionFailedError ex) {
 			throw new AssertionFailedError(name + ": " + ex.getMessage());
 		}
 	}
 
-	private boolean checkingProxyEquality(Method method, Object[] args) {
+	private boolean isCheckingEqualityOnProxy(Method method, Object[] args) {
 		return (method.getName().equals("equals")) && (args.length == 1) && (Proxy.isProxyClass(args[0].getClass()));
 	}
 	
-	private boolean gettingMockName(Method method, Object[] args) {
+	private boolean isMockNameGetter(Method method, Object[] args) {
 		return (method.getName().equals("getMockName")) && (args.length == 0);
 	}