mockobjects-java-users — For people who use the mock objects libraries

[Mockobjects-java-users] Re : Feature-Request

[Gilles D. <rh...@wa...>]

im really sorry about the previous post. this is the right one. could the =
moderator please  delete the previous one =3F


---- Message starts here ---

no, thats not what i mean : my MockConnection is a
MockConnection just as it is now. Although my
MockConnectionFactory would create the
MockPreparedStatement and the MockPreparedStatementFactory
would create the MockResultSet. calling verify on
myMockConnection would call verify myMockPreparedStatement
which in turn would verify myMockResultSet. the goal under
the request is to statically describe a reusable test
configuration, i.e. describe the configuration of mock
components in a xml file - in a kilim way
(http://www.objectweb.org/kilim). so instead of creating
and configuring MockObjects directly in the TestCase i
would delegate creation and configuration through a call of
type myMockConnection =3D
myConnectionFactory.getConnection("MockConnectionThatBehaves
LikeThat"); and i wouldnt worry about instantiating or
configuring neither the MockResultSet nor the
MockPreparedStatement anymore.
i think this is relevant since behaviour is often shared.
This could allow me to call the verify method *just* on
myMockConnection.
that approach is arguable, like i said in my previous post,
since it implies that the TestCase lost a bit of control
upon the test environment configuration. however i have the
intuition that it would be of much help. And also even if
you dont agree with the cascading verify idea, perhaps you
would with the factory one (i found kilim to be very
useful) =3F anyway im always interested in your point of
view.

thanks for your reply,

-- gd


>Messsage du 23/08/2002 12:30
>De : Nat Pryce <nat...@b1...>
>A : Gilles DODINET <rh...@wa...>
>Copie =E0 :
>Objet : Re: [Mockobjects-java-users] Feature-request 
>
> If I understand you, you want your MockConnection to
create your
> MockPreparedStatement and MockResultSet objects. I think
that's the
> wrong approach because you are putting too much real
implementation into
> your mock objects.
>
> Instead, create a MockConnection a MockPreparedStatement,
keep
> references both objects in variables in your test, tell
the connection
> to return the mock statement when createStatement() (or
whatever) is
> called, and verify both objects at the end of the test.
>
> Cheers,
> Nat.
>
> On Fri, 2002-08-23 at 12:00, Gilles DODINET wrote:
> > Hi,
> >
> > I think MockObjects are missing a feature very useful
when working with factories. imho they should follow the
Composite pattern. For instance, let's say i wanna use a
MockConnection : i need a MockPreparedStatement and a
MockResultset as well. If i want to externalize the
creation of my MockObjects from the TestCase perspective
(ok thats perhaps arguable), i have no practical way to do
it, since i will have to call verify() on both
myMockPreparedStatement and myMockResultset as well. But
since the creation of the MockObject was delegated, i lost
the references to those objects (and also
Verifier.verifyObject() doesnt verify myPreparedStatement :
it just ensure that it has been used).
> > There's also a crappy work-around : using AspectJ, we
can these functionnality at the price of extending
MockConnection, MockPreparedStatement and MockResultSet.
thats not satisfactory tho. so the better way i think would
be to modify MockObject class to make it composite. What do
you think of this =3F
> >
> > -- gd
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: OSDN - Tired of that
same old
> > cell phone=3F Get a new here for FREE!
> >
https://www.inphonic.com/r.asp=3Fr=3Dsourceforge1&refcode1=3Dvs339
0
> >
> > Mockobjects-java-users mailing list
> > Moc...@li...
> >
https://lists.sourceforge.net/lists/listinfo/mockobjects-jav
a-users
> --
> Dr. Nathaniel Pryce, Technical Director, B13media Ltd.
> Studio 3a, 22-24 Highbury Grove, London N5 2EA, UK
> http://www.b13media.com
>
>
>

[Mockobjects-java-users] Tr: Feature-request

[Gilles D. <rh...@wa...>]

i repost the reply i sent to nat cuz it seems ive replied to him without =
cc the list.

>Messsage du 23/08/2002 13:00
>De : Gilles DODINET <rh...@wa...>
>A :  <moc...@li...>
>Copie =E0 : 
>Objet : Feature-request  
>
> Hi,
> 
> I think MockObjects are missing a feature very useful when working with=
 factories. imho they should follow the Composite pattern. For instance, l=
et's say i wanna use a MockConnection : i need a MockPreparedStatement and=
 a MockResultset as well. If i want to externalize the creation of my Mock=
Objects from the TestCase perspective (ok thats perhaps  arguable), i have=
 no practical way to do it, since i will have to call verify() on both myM=
ockPreparedStatement and myMockResultset as well. But since the creation o=
f the MockObject was delegated, i lost the references to those objects (an=
d also Verifier.verifyObject() doesnt verify myPreparedStatement : it just=
 ensure that it has been used). 
> There's also a crappy work-around : using AspectJ, we can these functio=
nnality at the price of extending MockConnection, MockPreparedStatement an=
d MockResultSet. thats not satisfactory tho. so the better way i think wou=
ld be to modify MockObject class to make it composite. What do you think o=
f this =3F
> 
> -- gd
>

[Mockobjects-java-users] Feature-request

[Gilles D. <rh...@wa...>]

Hi,

I think MockObjects are missing a feature very useful when working with f=
actories. imho they should follow the Composite pattern. For instance, let=
's say i wanna use a MockConnection : i need a MockPreparedStatement and a=
 MockResultset as well. If i want to externalize the creation of my MockOb=
jects from the TestCase perspective (ok thats perhaps  arguable), i have n=
o practical way to do it, since i will have to call verify() on both myMoc=
kPreparedStatement and myMockResultset as well. But since the creation of =
the MockObject was delegated, i lost the references to those objects (and =
also Verifier.verifyObject() doesnt verify myPreparedStatement : it just e=
nsure that it has been used). 
There's also a crappy work-around : using AspectJ, we can these functionn=
ality at the price of extending MockConnection, MockPreparedStatement and =
MockResultSet. thats not satisfactory tho. so the better way i think would=
 be to modify MockObject class to make it composite. What do you think of =
this =3F

-- gd

[Mockobjects-java-users] RE: [MO-java-dev] com.mockobjects.io.MockWriter correction

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

I disagree with that change Steve. I know you prefer it - but its much
clearer to have a boolean parameter. It also allows for a clearer test when
you explicitly use false, to communicate that you really don't want an
exception. It also lets you set true in a test setup method and for an odd
test set it back to false.

-----Original Message-----
From: moc...@li...
[mailto:moc...@li...]On Behalf Of
Steve Freeman
Sent: 22 August 2002 10:53
To: moc...@li...; mockobjects users
Subject: Re: [MO-java-dev] com.mockobjects.io.MockWriter correction


I've checked this in twice.
1) more or less as you sent it.
2) invoking committer's privilege I've:
 - changed setWriteShouldThrowException() not to take a  parameter. The idea
is that new instances should
   be constructed for each test, so you shouldn't be toggling this value on
and off. It's either the default (off) or set.
- changed some variable names
- changed verify() to use the Verifier helper class.

If you don't like this let me know and we can rollback, in the meantime,
both versions are in CVS.

Steve

----- Original Message -----
From: "Francois Beausoleil" <fbe...@ft...>
To: <moc...@li...>
Sent: Thursday, August 22, 2002 3:08 AM
Subject: [MO-java-dev] com.mockobjects.io.MockWriter correction

> [...]




-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
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.381 / Virus Database: 214 - Release Date: 02/08/2002

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.381 / Virus Database: 214 - Release Date: 02/08/2002

[Mockobjects-java-users] Re: [MO-java-dev] com.mockobjects.io.MockWriter correction

[Steve F. <st...@m3...>]

I've checked this in twice.
1) more or less as you sent it.
2) invoking committer's privilege I've:
 - changed setWriteShouldThrowException() not to take a  parameter. The idea
is that new instances should
   be constructed for each test, so you shouldn't be toggling this value on
and off. It's either the default (off) or set.
- changed some variable names
- changed verify() to use the Verifier helper class.

If you don't like this let me know and we can rollback, in the meantime,
both versions are in CVS.

Steve

----- Original Message -----
From: "Francois Beausoleil" <fbe...@ft...>
To: <moc...@li...>
Sent: Thursday, August 22, 2002 3:08 AM
Subject: [MO-java-dev] com.mockobjects.io.MockWriter correction

> [...]

[Mockobjects-java-users] Re: [MO-java-dev] com.mockobjects.io.MockPrintWriter correction

[Steve F. <st...@m3...>]

Done. Imports tidied up as well.

S.


----- Original Message ----- 
From: "Francois Beausoleil" <fbe...@ft...>
To: <moc...@li...>
Sent: Thursday, August 22, 2002 2:51 AM
Subject: [MO-java-dev] com.mockobjects.io.MockPrintWriter correction


> Hello all !
> 
> I found a tiny problem with com.mockobjects.io.MockPrintWriter.  I have 
> included a diff to correct this problem.  The problem is a colon on the 
> author tag, which should not be there.  Javadoc chokes on it.
> [...]

Re: [Mockobjects-java-users] addBatch fail!

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

This method hasn't been implemented yet. If you let me know how you want
to use it I can implement it in the cvs version for you.

P.S. Looks like you've got an old version of the code as it should have
thown a NotImplementedException ;)


On Fri, 2002-08-16 at 02:46, Regis wrote:
> Hello,
>=20
> 	I wrote the code:
>=20
> 		MockConnection mockConnection;
> 		mockConnection =3D new MockConnection();	=09
> 	=09
> 		pst =3D new myClass( mockConnection );		=09
> 	=09
> 		MockStatement mockStatement  =3D new MockStatement();
> 	=09
> 		String sql =3D "insert into TUsuario ( cd_usuario,
> nm_usuario, dt_saida ) " +
> 					 "value ( 10, 'Regis Freire
> Melo', '2002-01-01' )";
> 					=20
> =09
> 		mockStatement.setExpectedExecuteCalls(1);
> 		mockConnection.setupStatement( mockStatement );
>=20
> 	But when I try to run the test, I receive the error:
>=20
> 			java.lang.UnsupportedOperationException =09
> 				at
> com.mockobjects.sql.MockStatement.addBatch(MockStatement.java:152) =09
> 				at
> XYZ.insert(SSPersistenceProprietary.java:259)
>=20
> 	The error occur in a line that do statement.addBatch.
> =09
> 	What's wrong?
>=20
> T.I.A.,
>=20
> /**
> * R=E9gis Melo
> * reg...@so...
> * +55(85)9111-8301
> * ICQ 159720027
> *=20
> * SoftSite Tecnologia
> * http://www.softsite.com.br
> * +55(85)261-5266=20
> * +55(85)273-1184=20
> *
> */
>=20
> "Find a job you love and=20
>  never work a day in your=20
>  life."=20
>  Confucius
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r_________________________________________=
______
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
--=20
jeff martin
information technologist
mkodo limited

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

www.mkodo.com

[Mockobjects-java-users] addBatch fail!

[Regis <re...@so...>]

Hello,

	I wrote the code:

		MockConnection mockConnection;
		mockConnection =3D new MockConnection();	=09
	=09
		pst =3D new myClass( mockConnection );		=09
	=09
		MockStatement mockStatement  =3D new MockStatement();
	=09
		String sql =3D "insert into TUsuario ( cd_usuario,
nm_usuario, dt_saida ) " +
					 "value ( 10, 'Regis Freire
Melo', '2002-01-01' )";
					=20
=09
		mockStatement.setExpectedExecuteCalls(1);
		mockConnection.setupStatement( mockStatement );

	But when I try to run the test, I receive the error:

			java.lang.UnsupportedOperationException =09
				at
com.mockobjects.sql.MockStatement.addBatch(MockStatement.java:152) =09
				at
XYZ.insert(SSPersistenceProprietary.java:259)

	The error occur in a line that do statement.addBatch.
=09
	What's wrong?

T.I.A.,

/**
* R=E9gis Melo
* reg...@so...
* +55(85)9111-8301
* ICQ 159720027
*=20
* SoftSite Tecnologia
* http://www.softsite.com.br
* +55(85)261-5266=20
* +55(85)273-1184=20
*
*/

"Find a job you love and=20
 never work a day in your=20
 life."=20
 Confucius

[Mockobjects-java-users] site inaccessible

[Steve F. <st...@m3...>]

Some of you may be wondering why the website www.mockobjects.com is
inaccessible.

We've been changing registrar and appear to have falled through the cracks
for the moment. Everything is still there on sourceforge.

Normal service will be resumed just as soon as we can.

Apologies

Steve

- - - - - - - - - - - - - - -
Steve Freeman
st...@m3...

"Nonsense is just nonsense, but the study of nonsense is science."

Re: [Mockobjects-java-users] how to contribute

[Steve F. <st...@m3...>]

Send it to me. Which version of Java is it for?

Steve

- - - - - - - - - - - - - - -
"Nonsense is just nonsense, but the study of nonsense is science."

----- Original Message ----- 
From: <mh...@at...>
To: <moc...@li...>
Sent: Monday, August 05, 2002 8:13 PM
Subject: [Mockobjects-java-users] how to contribute


> I have an implementation for wasNull in MockResultSet as well as for 
> previous().  I'd like to contribute them but don't know where to 
> start.  Thanks!
> 
> mike
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
> 

[Mockobjects-java-users] how to contribute

[<mh...@at...>]

I have an implementation for wasNull in MockResultSet as well as for 
previous().  I'd like to contribute them but don't know where to 
start.  Thanks!

mike

Re: [Mockobjects-java-users] Mock servlet objects--ready for use?

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

The idea is to focus attention on what is actually happening in your
code rather than what you suspect is happening.

I maybe a little more work in some cases to setup a list instead of the
map but the results can be worth it.

If you use a map you can write something like this.
 
String value = this.getAttribute("key1");
System.out.println("value = " + this.getAttribute("key1"));

and it will test the same as this

String value = this.getAttribute("key1");
System.out.println("value = " + value);

Now did I really mean to do it the first way or should I have done it
the second way. Chances are you really want the second, but if you have
a list you have to explicitly setup the extra values.

The other thing you get from using a list is left over objects. The list
in the MockHttpServletRequest will check that all the object in the list
have actually been used. 

So

stuff.setupGetAttribute("key1", "Value");
...
System.out.println("Value");
// should be System.out.println(stuff.getAttribute("key1"));

would be fine but with the list this would fail as you've reached the
end of the test without using the value you setup to be used.

It's probably a good idea to mention that this is a fair new development
in the Mocks so it's use might be a little in consistent.

Hope this helps

As for patches. Please do send them in. I've got a strong policy of only
implementing those thing I use so I expect people to send me in patches
of the bits they use and I don't.

diff -ub IveChanged.java

On Tue, 2002-07-23 at 23:39, Shellman, Joel wrote:
> I'm trying to use the mock servlet objects. The getAttribute(String)
> implementation of ServletRequest just returns something from a list instead
> of looking up in a HashMap or something like that. Why is this? How can a
> servlet that may set/get attributes any number of times function correctly
> with this implementation?
> 
> Also, I've put in some quick code so I can use RequestDispatcher as well. I
> might be able to contribute to the project (I would like to), though
> accessing CVS is difficult because our corporate firewall won't let me
> through.
> 
> Thanks,
> 
> Joel Shellman
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
-- 
Jeff Martin

Memetic Engineer

http://www.custommonkey.org/ 

[Mockobjects-java-users] Mock servlet objects--ready for use?

[Shellman, J. <Joe...@Su...>]

I'm trying to use the mock servlet objects. The getAttribute(String)
implementation of ServletRequest just returns something from a list instead
of looking up in a HashMap or something like that. Why is this? How can a
servlet that may set/get attributes any number of times function correctly
with this implementation?

Also, I've put in some quick code so I can use RequestDispatcher as well. I
might be able to contribute to the project (I would like to), though
accessing CVS is difficult because our corporate firewall won't let me
through.

Thanks,

Joel Shellman

Re: [Mockobjects-java-users] how to use?

[Steve F. <st...@m3...>]

From: "Oren Gross" <og...@me...>
To: <moc...@li...>
Sent: Tuesday, July 23, 2002 12:00 PM
Subject: [Mockobjects-java-users] how to use?


> Hi there
> I am probably the most fresh mock-objects user ever (I can count me
> experience in minutes).
> As a starter, I have a feeling that the only way for me to use mock
objects,
> is by implementing a basic interface used by the  tested object, and
sending
> it to this object, in order for it to use the mock and not the original
> object. If so, how can use mock objects for testing objects that do not
> expect such an argument, but create an instance of it inside?
> Thanks, Oren

one of the interesting effects of using mock objects is that it drives you
to pass objects around rather than hide them, which turns out to have some
nice effects on composability. In your case, depending on the circumstances,
you might pass in a factory. You can then subsitute another factory that
returns mocks -- it's a little bit of a pain, largely driven by inadequacies
in Java's object model. Alternatively, if the inner object has the same
lifetime as the container, we quite often cheat a little and try tricks like
overloading the contstructor:

public class Thing {
  public Thing(InnerThing innerThing) {
    inner = innerThings;
  }
  public Thing() {
    this(new DefaultInnerThing());
  }
}


public class ThingTest {
  public void testOne() {
    MockInnerThing mockInner = new MockInnerThing();
    Thing aThing = new Thing(mockInner);
    ...

public class RealCode {
    ...
    Thing aThing = new Thing();
    // do something with it...


Steve

Re: [Mockobjects-java-users] how to use?

[Olaf K. <ok...@ab...>]

Oren Gross wrote:
> 
> If so, how can use mock objects for testing 
> objects that do not expect such an argument, 
> but create an instance of it inside?

Hi Oren,

probably the nicest thing in TestDrivenDevelopment is, that
the responsibility for creation of objects gets turned upside
down - or inside out if you prefer so... 

If you write Tests that want to parameterize an object with a
mock implementation you need a way to provide this from
outside. The bad way (but sometimes reasonable) would be to
"inject" a MockObject, using a method that is there only for
injecting it during the test run.
A probably better way would be to have the subsystem designed
in a way that they get their collaborators set from outside,
e.g. during creation in a factory or builder (or testcase).
You get this almost naturally with TestDrivenDevelopment
(http://c2.com/cgi/wiki?TestDrivenDevelopment).

In any case, you need to refactor the creation of the objects
to a place both the runtime- and the test-environment can
access.

One thing more: Beware of using MockObject to replace each and
every instance of collaborator interfaces in testing: You
might loose flexibility and the ability to refactor
mercilessly.
<shamelessAdvert>
  Beware of it even if there is a new version 
  of MockCreator available for Eclipse, VAJ and 
  CommandLine (www.abstrakt.de/mockcreator.html) 
  ;-)
</shamelessAdvert>
But of course, your milage may vary...

My advice is to get deep into TestDrivenDevelopment, this will
almost automagically lead to MockObjects at some point (if
this is not the way you went up to where you are now;-)

Olaf
-- 

abstrakt gmbh, Behringstrasse 16b, 22765 Hamburg 
Tel: +49-40-39804630, Fax: +49-40-39804639

http://www.abstrakt.de/

[Mockobjects-java-users] how to use?

[Oren G. <og...@me...>]

Hi there
I am probably the most fresh mock-objects user ever (I can count me
experience in minutes).
As a starter, I have a feeling that the only way for me to use mock objects,
is by implementing a basic interface used by the  tested object, and sending
it to this object, in order for it to use the mock and not the original
object. If so, how can use mock objects for testing objects that do not
expect such an argument, but create an instance of it inside?
Thanks, Oren

____________________________________
Oren Gross Java(TM) Developer
Mercury Interactive APM TAC R&D 
+972-3-5399407 og...@me...

Re: [Mockobjects-java-users] MockObjects and Factories best practices

[Steve F. <st...@m3...>]

One of the points of the original paper is that the need to substitute mock
implementations pushes you to pass objects around a lot more than most of us
have been used to -- a "compositional" style of programming. This can force
you into having lots of parameters in a signature, but that's usually a sign
that there's an intermediate object waiting for you to group some behaviour
together.

Sometimes this means passing in factories when constructing an object, and
the one concession to testing we sometimes make is to have two constructors:
one which allows you to set various instance fields (so you can substitute
some mocks), and one which sets up those fields with default
implementations, e.g.

class ThingDoer {
  private FooFactory fooFactory;
  public ThingDoer(FooFactory aFooFactory) {
    fooFactory = aFooFactory;
  }
  public ThingDoer() {
    this(new HttpFooFactory());
  }

- - - -
Concerning the original question, I'm currently doing quite a lot of test
retrofitting. One of the tricks for dealing with singletons is to declare an
interface, attach it to the singleton object, and pass it in to the calling
object. e.g.

class Notifier {...

class ThingDoer {
  public void makeItSo() {
    doStuff();
    Notifier.tellTheWorld("we did it");
  }
}

becomes

class AsynchNotifier implements Notifier {...

class ThingDoer {
  private Notifier notifier;
  public ThingDoer(Notifier aNotifier) {
    notifier = aNotifier;
  }
  public void makeItSo() {
    doStuff();
    notifier.tellTheWorld("we did it");
  }
  // or, alternatively
  public void makeItSo(Notifier notifier) {
    doStuff();
    notifier.tellTheWorld("we did it");
  }

You can now test the use of the notifier by passing a mock implementation
somewhere and, quite often, it turns out that it shouldn't have been a
singleton after all.

b.t.w., there's a SingletonsAreEvil page on the C2 wiki.

Steve

Re: [Mockobjects-java-users] MockObjects and Factories best practices

[Olaf K. <ok...@ab...>]

Paul Jackson wrote:
> 
> The approach we have been taking is to extend a Factory with a MockFactory have a static Factory.setInstance(Factory f) that allows us to setup the MockFactory as the real factory.
> 
> That is assuming that we use a singleton pattern to return the Factory (or MockFactory) with the static Factory.instance() method.
> 
> Is this the best approach or is there a better one?

It's a valid approach, if there is a better one depends upon
your needs. I personally prefer "building" fully configured
Objects rather than leaving configuration to them - thus
needing factory singletons to callback to the environment.
After all, singletons are the object oriented globals. Sorry,
I don't have the reference to "Singletons Are Evil" at hand.
Probably somebody else could jump in.

If you build configured objects, a builder (or anything else
constructing them - I'm not necessarily talking exclusively
about the GOF-Builder here) can configure an object one way,
the testcode will configure them differently. This way
testcode doesn't need to bother with factories, messing up
singletons with the need for cleanups later and unpredictable
side effects, if this cleanup is forgotten.

Olaf

-- 

abstrakt gmbh, Behringstrasse 16b, 22765 Hamburg 
Tel: +49-40-39804630, Fax: +49-40-39804639

http://www.abstrakt.de/

RE: [Mockobjects-java-users] MockObjects and Factories best practices

[Paul J. <pau...@me...>]

The approach we have been taking is to extend a Factory with a =
MockFactory have a static Factory.setInstance(Factory f) that allows us =
to setup the MockFactory as the real factory.

That is assuming that we use a singleton pattern to return the Factory =
(or MockFactory) with the static Factory.instance() method.

Is this the best approach or is there a better one?

For example, the code would look like this...

	public class Factory {
		private Factory factory =3D null;

		public static instance() {
			if (factory =3D=3D null) {
				factory =3D new Factory();
			}
			return factory;
		}

		public static setInstance(Factory pFactory) {
			factory =3D pFactory;
		}

		public Bean getBean() {
			return new Bean();
		}
	}

	public class MockFactory extends Factory {
		public Bean getBean() {
			return new MockBean();
		}
	}


Paul Jackson
Meridian Informatics

Phone: (02) 8233 7564
Mobile: 0418 855 496




-----Original Message-----
From: moc...@li...
[mailto:moc...@li...]On Behalf Of
Olaf Kock
Sent: Friday, 28 June 2002 3:43 AM
To: Moc...@li...
Subject: Re: [Mockobjects-java-users] MockObjects and Factories best
practices


Hi John,

John Sisk wrote:
>=20
> Hi there,
>=20
> What is the best practice for integrating mocks into a project?=20

The key point is to shift object creation from classes to be
tested to somewhere outside. That doesn't necessarily meen a
factory to be involved, but the class in question will be
parameterized with their collaborators from somewhere outside
(probably/sometimes in the constructor).

This way production code constructs objects and parameterizes
them with "real" collaborators (and may do so with the use of
factories or builders). Testcode on the other hand directly
creates objects under test and parameterizes them with
MockObjects suiting its particular needs.

Don't pollute factories with mockobjects. (That is - if you
wanted to ask that and I understood correctly). Production
code should be able to be delivered without any MockObject.

Hope that helps?

Olaf

--=20

abstrakt gmbh, Behringstrasse 16b, 22765 Hamburg=20
Tel: +49-40-39804630, Fax: +49-40-39804639

http://www.abstrakt.de/

Re: [Mockobjects-java-users] MockObjects and Factories best practices

[Olaf K. <ok...@ab...>]

Hi John,

John Sisk wrote:
> 
> Hi there,
> 
> What is the best practice for integrating mocks into a project? 

The key point is to shift object creation from classes to be
tested to somewhere outside. That doesn't necessarily meen a
factory to be involved, but the class in question will be
parameterized with their collaborators from somewhere outside
(probably/sometimes in the constructor).

This way production code constructs objects and parameterizes
them with "real" collaborators (and may do so with the use of
factories or builders). Testcode on the other hand directly
creates objects under test and parameterizes them with
MockObjects suiting its particular needs.

Don't pollute factories with mockobjects. (That is - if you
wanted to ask that and I understood correctly). Production
code should be able to be delivered without any MockObject.

Hope that helps?

Olaf

-- 

abstrakt gmbh, Behringstrasse 16b, 22765 Hamburg 
Tel: +49-40-39804630, Fax: +49-40-39804639

http://www.abstrakt.de/

[Mockobjects-java-users] MockObjects and Factories best practices

[John S. <jo...@si...>]

Hi there,

What is the best practice for integrating mocks into a project? I guess my
question is, what is the easiest way to get started with mocks, without the
overhead of implementing a lot of factories. Or is it essential to use
factories so you can configure to use mocks for testing and real objects in
production?

Regards
John Sisk

[Mockobjects-java-users] RE: Stubs vs. Mock Objects

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

Hi Andrew,

> -----Original Message-----
> From: Andrew Batishchev [mailto:aba...@ta...]
> Sent: 20 June 2002 18:14
> To: vm...@oc...
> Subject: Stubs vs. Mock Objects
> 
> Dear Vincent,
> The www.mockobjects.com site announces that you and Steve Freeman
> volunteered to share your vision of the subject.
> 
> Before you publish "a page explaining the differences between Mock
Objects
> and Stubs as it is largely misunderstood" at (which we are waiting
for,
> patiently)
> could you be so kind to give us some advice where we can find some
> resources
> 
> on this matter.
> 

I would suggest you read the PDF first that is available on the web
site.

> Can we draw a fine line between these two concepts?
> 
> Are mock objects extremely stupid and controlled by the unit test,
when
> stubs have some brains of their own?
> 

yes!

Mock objects = stupid empty placeholders. They just have setters and
getters and no logic. They are 100% controlled by the test case, which
calls the correct methods to put them in a desirable state, tell then to
throw exception when such method is called, etc.

Stubs = simple implementation that is replacing the real one. It is
simpler than the real one but still implementing the same logic (at
least the same interface _seen from the outside_). Eg, A method might
throw an exception if such file is not present on disk and if it is then
return it's value. A stub would have some logic and perform an "if" to
implement that logic. A more intelligent stub would be able to be
controlled by some configuration flag or would provide an API .. haha
this is when the 2 concepts start to merge

Let's say that a Mock Objects is like a stub for which you would have
100% of its logic been made parametrizable as an API that is controlled
by the test case.


> Is it possible for you to describe this difference in some condensed
form,
> just by a couple of sentences?
> 
> Sorry to bother you , but I am really desperate - I find myself in the
> middle of the new "To-Mock-or-not-to-Mock" holy war.

Either do in-container testing like Cactus or mock. Stubs is not a good
solution to me. It can be sometime for code that is not well written and
you want to see as a black box.

Cheers,
-Vincent

> 
> Just links to the resources would be splendid.
> 
> Thank you in advance
> Sincerely
> 
> Andrew Batishchev
> Software developer
> 
> Universal Tax Systems
> (706)624-4245 x 2265
> 
> 
> The information contained in this electronic message from Universal
Tax
> Systems, Inc., and any attachments, contains
> information that is confidential and/or privileged.  If you are not
the
> intended recipient, you are hereby notified that
> any disclosure, copying, distribution or use of this information is
> strictly prohibited.  If you have received this
> communication in error, please notify Universal Tax Systems, Inc.,
> immediately by e-mail or by telephone at 706/625-7757,
> and destroy this communication.  Thank you.
> 

Re: [Mockobjects-java-users] the setExpectNothing method

[Steve F. <st...@m3...>]

You can overspecify, as well as underspecify, unit tests. We tried
defaulting to 'hard' verification but found that it just got in the way,
especially with mock objects that have multiple expectations that are
used in different situations. We also found that specifying 'expect
nothing' explicitly makes the tests more self explanatory.

S.

----- Original Message -----
From: "Stephen Peterson" <csp...@ya...>
To: <moc...@li...>
Sent: Tuesday, June 04, 2002 2:46 PM
Subject: [Mockobjects-java-users] the setExpectNothing method


> Hi,
>
> I was looking over the setExpectNothing() method on classes like
> ExpetationValue.
>
> How come this method isn't called as part of the
> ExpectationValue constructor?
>
> Doing so would make tests fail when calls are made that are not
> covered in the test.  Wouldn't this be a good thing, since it
> would force the tester to write more complete tests?
>
> Please share your insights with me.
>
> thanks
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
>

[Mockobjects-java-users] the setExpectNothing method

[Stephen P. <csp...@ya...>]

Hi,

I was looking over the setExpectNothing() method on classes like
ExpetationValue.

How come this method isn't called as part of the
ExpectationValue constructor? 

Doing so would make tests fail when calls are made that are not
covered in the test.  Wouldn't this be a good thing, since it
would force the tester to write more complete tests?

Please share your insights with me.

thanks


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Re: [Mockobjects-java-users] question with introductory papers

[Steve F. <st...@m3...>]

just a quickie before running off to XP2002...

From: "Stephen or Carlene Peterson" <csp...@ya...>
> I find applying Mock-Objects and writing my tests first to be
> very difficult.  Often when adding new code, it seems tortuously
> slow, which suggests that I am just not 'getting' it.  Usually
> time pressure compells me to skip writing tests first, and this
> frustrates me.  I totally buy into the test-first-design
> philosophy, but have trouble applying it.

It can take a while when starting a new lump of code to build a critical
mass of test infrastructure. The most useful part of test-first is its
effect on design. How long can do you go before dropping out?

> I have domain-code that receives objectA as a parameter.
> It needs to call method isObjectNull on object A with a string
> parameter "LockingTableName".  The simple case is where a true
> is returned, and the program exists.  Another test is where a
> false returns, and then a series of calls are made.
>
> I need to verify that calls are made, sometimes with certain
> parameters and return values.  How do I do this?
>
> The example code in the Endo-Testing example shows the
> domain-code, the test-code, but does not show the code
> implementing the mock objects.  For example:
>

public void testUpdateEmployee() throws SQLException {
  MockObjectA mockA = new MockObjectA();
  mockA.setupIsObjectNull(true);

  mockA.setExpectedTableName("LockingTableName");

  obj.isObjectNull(mockA);

  mockA.verify();
}

class MockObjectA implements Verifiable {
  private boolean isObjectNull;
  private ExpectationValue tableName = new ExpectationValue("table
name");
  public void setupIsObjectNull(boolean isNull) {
    isObjectNull = isNull;
  }
  public void setExpectedTableName(String name) {
    tableName.setExpected(name);
  }
  public boolean isObjectNull(String name) {
    tableName.setActual(name);
  }
  // if you inherit from MockObject, there's a verify() method that
works using reflection.
  public void verify() {
    tableName.verify();
  }
}

That said, I've been moving towards a lighter style for small mock
objects, using inner classes with local variables. Still, this will get
you started.

S.