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

[Mockobjects-java-users] Correction on: question with introductory papers

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

I apologize for my incomplete thoughts on the prior email.

The send button was hit accidentally!  I was trying to clarify
my thoughts though writing an email, but the thoughts were not
yet clear.  For now on I will try to do this outside my email application!

__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

[Mockobjects-java-users] question with introductory papers

[Stephen or C. P. <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 seems like a broader spectrum of examples would be helpful in
the introductory papers, and maybe my questions might help in
developing those.  Can anyone else on this list identify with
me, who is maybe reluctant to expose the extent of their
struggles?

Here is a situation I am unsure of, and have not found an answer
after re-reading the 2 intro papers.

I will lay it 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 {


 

So I create MockObjectA. 





__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

Re: [Mockobjects-java-users] Question on best practices

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

From: <lau...@ma...>
> On  8 May, Steve Freeman wrote:
> > Do you have an example?
>
> Well, something like this:
>
> Foo methodToTest() {
>   ObjectHome home = mockFactory.getHomeObject();
>   Object o = home.create()
>
>   return o.getFoo();
> }
>
> In order for this method to be tested correctly, o has to be avalid
object.
> I have two way of doing this: either Home.create() implements all the
logic
> to create a correct Foo object (and in our case, sometimes that's a
> multi-step operation) or I add a setupFoo(Foo o) method that will
> effectively do the same thing, but the multi-step operation occurs
outside
> of the mock object that is returned by getHomeObject().

In that case, then you would probably want a mock factory, mock home
object, and mock o. It's a pain, but it's quite easy to set up using
anonymous implementations in the test class until the mock gets useful
enough to pull out into its own class: e.g.

public void testMethodToTest() {
    final Foo aFoo = new Foo();
    final AnObject mockO = new AnObject() {
       public Foo getFoo() {
          return aFoo;
       }
    };
    final ObjectHome mockHome = new ObjectHome() {
      public AnObject create() {
        return mockO;
      }
    };
    Factory mockFactory = new Factory() {
      public HomeObject getHomeObject() {
         return mockHome;
      }
    };

    testObject.setFactory(mockFactory);
    assertEquals("Should be a foo", aFoo, testObject.methodToTest());
}

or some such madness. It shouldn't be long before you can refactor out
all this setup into something more readable.

> I think what I need to understand is where do I stop reimplementing
the
> logic of my real application in the mock object?

almost immediately. If you reimplement the real application, then you've
just got more to test.

S.

Re: [Mockobjects-java-users] Question on best practices

[<lau...@ma...>]

On  8 May, Steve Freeman wrote:
> Do you have an example?
> 

Well, something like this:

Foo methodToTest() {
  ObjectHome home = mockFactory.getHomeObject();
  Object o = home.create()

  return o.getFoo();
}

In order for this method to be tested correctly, o has to be avalid object.
I have two way of doing this: either Home.create() implements all the logic
to create a correct Foo object (and in our case, sometimes that's a
multi-step operation) or I add a setupFoo(Foo o) method that will
effectively do the same thing, but the multi-step operation occurs outside
of the mock object that is returned by getHomeObject().

I think what I need to understand is where do I stop reimplementing the
logic of my real application in the mock object?

L

-- 
Laurent Duperval <mailto:lau...@ma...>

There are two rules for success in life:
Rule 1:  Don't tell people everything you know.

Re: [Mockobjects-java-users] Question on best practices

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

From: <lau...@ma...>

> trying to create)? Or should I set up the object beforehand and have
the
> create() method make sure it is called and then return the data I have
> previously set up?

What are you trying to test? If you want to test that some other code
talks to the create() method correctly, then I would check that it's
called appropriately and pre-load the result. The point is to mock up
the environment around so that you can isolate the code under test. On
the other hand, if it's easy to create and instance and you don't need
to do anything with it in the rest of the test, then maybe you could
just assert that the object returned from create() is of the right type?

Do you have an example?

S.

[Mockobjects-java-users] Question on best practices

[<lau...@ma...>]

Hi,

I'm in the process of writing some tests with Cactus and MO. Iwant to
simulate some Session Beans so I've written mock objects for them. Some of
our session beans have a create() method to simulate the corresponding home
interface method from the session bean interface. When I implement my mock
object, should the create() method actually create a real object and return
it (so, I would have to create another  mock to implement the interface I'm
trying to create)? Or should I set up the object beforehand and have the
create() method make sure it is called and then return the data I have
previously set up?

Hope it's not too confusinng an explanation.

L

-- 
Laurent Duperval <mailto:lau...@ma...>

Windows 3.1:  The 8MB patch.

Re: [Mockobjects-java-users] Beginner questions

[<lau...@ma...>]

On 22 Apr, Vincent Tence wrote:
> getParametersMap() is not yet implemented but attached is a patch that does it. 
> Best is to add the expected behavior to the Mock rather than extending it. We implement little by 
> little as our needs grow.
> 

Ok, that's fair. I guess I didn't understand it like that.

Thanks,

L

-- 
Laurent Duperval <mailto:lau...@ma...>

Velilind's Laws of Experimentation:
        1.  If reproducibility may be a problem, conduct the test only once.
        2.  If a straight line fit is required, obtain only two data points.

[Mockobjects-java-users] [Fwd: Sourceforge page]

[Vincent T. <vt...@sy...>]

Forwarding this to the right list, sorry.

[Mockobjects-java-users] Sourceforge page

[Vincent T. <vt...@sy...>]

Guys,

I've been to the sourceforge project's page and I was wondering if
anyone one is taking care of bugs and patches submitted to the tracker.

I saw some stuff there a few months old and I don't know if the poor
guys even got an answer. I am willing to help answering people questions
where I can but I don't know how that tracker works.

-- Vincent

Re: [Mockobjects-java-users] Beginner questions

[Vincent T. <vt...@sy...>]

Laurent,

Jeff has been busy recently reorganizing the CVS tree. You should get the latest source from CVS. 
Mocks for servlet 2.3 are located under j2ee/1.3/com/mockobjects/servlet.

getParametersMap() is not yet implemented but attached is a patch that does it. 
Best is to add the expected behavior to the Mock rather than extending it. We implement little by 
little as our needs grow.

Guys, can anyone of you review the patch and apply it if it makes sense (it's pretty late for me now ;-))

-- Vincent
 


On Mon, 2002-04-22 at 19:32, lau...@ma... wrote:
> On 22 Apr, To: MockObjects Users List wrote:
> > and the test code (I modified it a bit since my earlier post):
> > 
> >     public void setUp() {
> >         servletRequest = new MockHttpServletRequest();
> >         servletRequest.setupAddParameter("param1", "value1");
> >         servletRequest.setupAddParameter("param2", "value2");
> >         servletRequest.setupAddParameter("param3", "value3");
> >     }
> > 
> >     public void testNoMissingParameters() {
> >         String[] requiredParams = { "param1", "param2", "param3" };
> >         parser = new ParameterParser(requiredParams, servletRequest);
> >         assertTrue("Required parameter missing ", parser.getMissingParameters() == null);
> >     }
> > 
> 
> Ok, so I changed the test code to add this:
> 
>     class TestMockHttpServletRequest extends MockHttpServletRequest {
> 
>         HashMap paramMap = new HashMap();
> 
>         TestMockHttpServletRequest() {
>             super();
>         }
> 
>         public void setupAddParameter(String s, String s1) {
>             super.setupAddParameter(s, s1);
>             paramMap.put(s, s1);
>         }
> 
>         public Map getParameterMap() {
>             return paramMap;
>         }
>     }
> 
> and I use this class as my mock object. I now get the expected behaviour.
> However, I'm not sure that's the correct way to do things.
> 
> L
> 
> -- 
> Laurent Duperval <mailto:lau...@ma...>
> 
> Murphy's Laws for Frequent Flyers
> 2.  If you are running late for a flight, it will depart from the farthest
>     gate within the terminal.
> 
> 
> 
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users

Re: [Mockobjects-java-users] Beginner questions

[<lau...@ma...>]

On 22 Apr, To: MockObjects Users List wrote:
> and the test code (I modified it a bit since my earlier post):
> 
>     public void setUp() {
>         servletRequest = new MockHttpServletRequest();
>         servletRequest.setupAddParameter("param1", "value1");
>         servletRequest.setupAddParameter("param2", "value2");
>         servletRequest.setupAddParameter("param3", "value3");
>     }
> 
>     public void testNoMissingParameters() {
>         String[] requiredParams = { "param1", "param2", "param3" };
>         parser = new ParameterParser(requiredParams, servletRequest);
>         assertTrue("Required parameter missing ", parser.getMissingParameters() == null);
>     }
> 

Ok, so I changed the test code to add this:

    class TestMockHttpServletRequest extends MockHttpServletRequest {

        HashMap paramMap = new HashMap();

        TestMockHttpServletRequest() {
            super();
        }

        public void setupAddParameter(String s, String s1) {
            super.setupAddParameter(s, s1);
            paramMap.put(s, s1);
        }

        public Map getParameterMap() {
            return paramMap;
        }
    }

and I use this class as my mock object. I now get the expected behaviour.
However, I'm not sure that's the correct way to do things.

L

-- 
Laurent Duperval <mailto:lau...@ma...>

Murphy's Laws for Frequent Flyers
2.  If you are running late for a flight, it will depart from the farthest
    gate within the terminal.

Re: [Mockobjects-java-users] Beginner questions

[<lau...@ma...>]

On 22 Apr, Scott Lamb wrote:
> On Mon, Apr 22, 2002 at 01:25:44PM -0400, lau...@ma... wrote:
>> in the testNoMissingParameters() method, I get an error. This kinda tell=
s me
>> that I'm not setting up the servlet properly. Am I correct in my assessm=
ent?
>> What am I not understanding at this point?
>=20
> What sort of error? Your test code looked good to my semi-educated eye. A=
re
> you sure it is not working correctly and finding a bug in the code you ar=
e
> testing?
>=20

Sorry, I have to learn to speak properly; I should've said failure:

Time: 0.039
There was 1 failure:
1) testNoMissingParameters(ca.masq.servlet.ParameterParser_UnitTest)junit.f=
ramework.AssertionFailedError: Required parameter missing=20
=09at ca.masq.servlet.ParameterParser_UnitTest.testNoMissingParameters(Para=
meterParser_UnitTest.java:72)

This is my code:

    public ParameterParser(String[] requiredParams, HttpServletRequest aReq=
uest) {
        request =3D aRequest;
        if (request =3D=3D null) {
            throw new IllegalArgumentException("Null request received");
        }
        requestParameters =3D request.getParameterMap();
        requiredParameters =3D requiredParams;
    }

and the test code (I modified it a bit since my earlier post):

    public void setUp() {
        servletRequest =3D new MockHttpServletRequest();
        servletRequest.setupAddParameter("param1", "value1");
        servletRequest.setupAddParameter("param2", "value2");
        servletRequest.setupAddParameter("param3", "value3");
    }

    public void testNoMissingParameters() {
        String[] requiredParams =3D { "param1", "param2", "param3" };
        parser =3D new ParameterParser(requiredParams, servletRequest);
        assertTrue("Required parameter missing ", parser.getMissingParamete=
rs() =3D=3D null);
    }

So I expect request.getParameterMap() to return a Map containing the keys
"param1", "param2" and "param3". But when I run in the debugger, it returns
null. So I expect there's something I'm misunderstanding.

L


--=20
Laurent Duperval <mailto:lau...@ma...>

La lettre, exsangue et chiffonn=E9e, hors d'haleine mais triomphante, about=
it
enfin entre les mains de celui qui suscita toute l'extraordinaire odyss=E9e
d'=E9motion que je viens de vous narrer: MOI!
                                             -Achille Talon

Re: [Mockobjects-java-users] Beginner questions

[Scott L. <sl...@sl...>]

On Mon, Apr 22, 2002 at 01:25:44PM -0400, lau...@ma... wrote:
> in the testNoMissingParameters() method, I get an error. This kinda tells me
> that I'm not setting up the servlet properly. Am I correct in my assessment?
> What am I not understanding at this point?

What sort of error? Your test code looked good to my semi-educated eye. Are
you sure it is not working correctly and finding a bug in the code you are
testing?

If you are just seeing "this test caused an error", you are not seeing all
the output junit is producing - it should have more helpful information. How
are you running junit? I typically run it as an ant task, configured to say
something like that but also produces a report file with more verbose
output.

--
Scott Lamb

[Mockobjects-java-users] Beginner questions

[<lau...@ma...>]

Hi,

I'm having a hard time wrapping my head around this MO concept. I think I
need some help. I'm writing a general purpose parameter parser for servlets.
Basically, I want the servlet to validate that all required parameters are
part of the request. So in my parser tests, I want to use a mock object (a
MockHttpServletRequest) to implement the request parameter of my method.
Now, my test looks like this:


/*
 * Test for ParameterParser
 */
package ca.masq.servlet;

import junit.framework.TestCase;
import junit.framework.Test;
import junit.framework.TestSuite;

import javax.servlet.http.HttpServletRequest;

import com.mockobjects.*;
import com.mockobjects.*;
import com.mockobjects.util.TestCaseMo;
import com.mockobjects.servlet.MockHttpServletRequest;

public class ParameterParser_UnitTest extends TestCaseMo {

    ParameterParser parser;
    MockHttpServletRequest servletRequest;

    public ParameterParser_UnitTest(java.lang.String testName) {
        super(testName);
    }

    public static void main(java.lang.String[] args) {
        junit.textui.TestRunner.run(suite());
    }

    public static Test suite() {
        TestSuite suite = new TestSuite(ParameterParser_UnitTest.class);

        return suite;
    }

    public void setUp() {
        servletRequest = new MockHttpServletRequest();
    }

    public void testCreateWithNullRequest() {
        try {
            parser = new ParameterParser(new String[] {"foo"}, null);
            fail("Exception expected");
        } catch (IllegalArgumentException iae) {
            assertTrue(true);
        }
    }

	.
	.
	.

    /*
     * No error occurs here.
     */
    public void testNoMissingParameters() {
        String[] requiredParams = { "param1", "param2", "param3" };
        servletRequest.setupAddParameter("param1", "value1");
        servletRequest.setupAddParameter("param2", "value2");
        servletRequest.setupAddParameter("param3", "value3");
        parser = new ParameterParser(requiredParams, servletRequest);
        assertTrue("Required parameter missing", parser.getMissingParameters() == null);
    }

}

in the testNoMissingParameters() method, I get an error. This kinda tells me
that I'm not setting up the servlet properly. Am I correct in my assessment?
What am I not understanding at this point?

Thanks,

L

-- 
Laurent Duperval <mailto:lau...@ma...>

You won't strain your eyes if you look at the bright side of things
    --Winston Churchill

[Mockobjects-java-users] RE: jdbc 3.0 compliant mockobjects

[mh983 <mh...@su...>]

How about a version of the sql classes that compiles under
jdk1.3 AND jdk1.4 as an interim measure?  All of the new
jdbc methods could throw unsupported operation exceptions,
but anyone coding to the interface from 1.3 wouldn't even
know those operations existed.  This code could be put into
place right now.

The issue seems to be that if you release a version of
mockobjects that actually uses some new 1.4 functionality or
a class that didn't exist previously, then you'll need a
separate code branch to support all the 1.3 users.

just a thought.

mike
_____________________________________________________________________
// free anonymous email || forums \\ subZINE || anonymous browsing 
            subDIMENSION -- http://www.subdimension.com

Re: [Mockobjects-java-users] code submission: how to

[Giuseppe G. <gg...@e-...>]

hi steve,
you can find the modified source code in attachment.
Please, note that I used my own code convenction and that my changes are 
limited to some issues in the previus version (mockobjects-atg-dynamo, 
Initial version of April 28, 2001)
HTH
Pino


At 07.30 16/04/2002, you wrote:
>If you send it to us, we can check it in. Unfortunately, I don't have
>access to the Dynamo any more, so I can't build that package.
>
>Steve
>
>----- Original Message -----
>From: "Giuseppe Galli" <gg...@e-...>
>To: <moc...@li...>
>Sent: Monday, April 15, 2002 4:57 PM
>Subject: [Mockobjects-java-users] code submission: how to
>
>
> > hi all,
> > how can I know if my work done on the code in the package
> > com.mockobjects.atg can be shared amoung other people?
> > Pino
> >
> >
> > _______________________________________________
> > Mockobjects-java-users mailing list
> > Moc...@li...
> > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
> >

[Mockobjects-java-users] code submission: how to

[Giuseppe G. <gg...@e-...>]

hi all,
how can I know if my work done on the code in the package 
com.mockobjects.atg can be shared amoung other people?
Pino

Re: [Mockobjects-java-users] simulating vs. reproducing behavior

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

From: "Brian Denny" <br...@dl...>
> but Version C is the only one of the three that really specifies what
i am
> trying to test.  if i am writing a function to update a bunch of
objects in
> a database, what i care about is that the objects got updated
correctly.  i
> don't care HOW they got updated.  Version A and B both test that the
update
> happened a certain way.
>
> maybe this whole dilemma is the fault of JDBC, because it provides 2
> different *interfaces* for accomplishing the same functionality...?
but on
> the other hand, it would be nice to be able to write test code that
would
> pass even if i decided to re-implement my update() by making a raw
socket
> connection to the SQL server...

it seems to me that, at some point, you have to exercise your jdbc code.
When you come to do that, I hope you find mocks useful. If version C is
what you want to achieve, then maybe you need some intermediate objects
to buffer that which, in turn, can be mocked up?

Steve

Re: [Mockobjects-java-users] simulating vs. reproducing behavior

[Brian D. <br...@dl...>]

i think that our previous conversation diverged a bit from the point i was
trying to make.

here are three possible versions of a test method:

// VERSION A //
public void testUpdate() throws Exception {

  myMockStatement.setExpectedQueryString(UPDATE_QUERY);
  myMockStatement.setExpectedExecuteCalls(1);

  mySQLObj.setMyInstanceVariable("different value"); // marks isChanged
  SQLUtils.update(myMockConnection, objs);

  myMockStatement.verify();
}

// VERSION B //
public void testUpdate() throws Exception {

  myMockResultSet.setupRows( { ... } );

  myMockResultSet.setExpectedUpdateRowCalls(1);  // this line tests
implementation details

  mySQLObj.setMyInstanceVariable("different value"); // marks isChanged
  SQLUtils.update(myMockConnection, objs);

  myMockResultSet.verify();
}

// VERSION C //
public void testUpdate() throws Exception {

  myMockResultSet.setupRows( { ... } );
  SQLObject[] objs = SQLUtils.fetch(myMockConnection, IDS_TO_FETCH);
  objs[0].setMyInstanceVariable("different value"); // marks isChanged
  SQLUtils.update(myMockConnection, objs);

  SQLObject[] objs = SQLUtils.fetch(myMockConnection, IDS_TO_FETCH);
  assertEquals("different value", objs[0].getMyInstanceVariable());
}


Version A seems very MockObjects-ish.  i think it is clear that Version A
assumes that you are performing the update by calling executeUpdate() on a
statement.

Version B also seems very MockObjects-ish.  version B, on the other hand,
assumes that you are performing the update by getting a resultset and
calling rs.updateRow() on the resultset.

Version C doesn't seem very MockObjects-ish, primarily because you'd have to
implement a lot of not-so-mock functionality in your mock objects to make it
work.

but Version C is the only one of the three that really specifies what i am
trying to test.  if i am writing a function to update a bunch of objects in
a database, what i care about is that the objects got updated correctly.  i
don't care HOW they got updated.  Version A and B both test that the update
happened a certain way.

maybe this whole dilemma is the fault of JDBC, because it provides 2
different *interfaces* for accomplishing the same functionality...?  but on
the other hand, it would be nice to be able to write test code that would
pass even if i decided to re-implement my update() by making a raw socket
connection to the SQL server...

-brian















> Yups!
>
>
>
>
> > so, all your updates will be done using an SQL query, rather than by
using
> > an updatable result set, right?
>
> > -brian
>

RE: [Mockobjects-java-users] simulating vs. reproducing behavior

[Verma, N. (G. B. L529706) <Nit...@ge...>]

Hi Steve,

Thanx!
I suppose anyone havin' bit of XP in blood will have similar answer!
Anyway special thanx to my guru "Chad Fowler"!

Cheers XP!

Regards,

Nitin Verma

-----Original Message-----
From: Steve Freeman [mailto:st...@m3...]
Sent: Monday, March 11, 2002 5:22 AM
To: moc...@li...
Subject: Re: [Mockobjects-java-users] simulating vs. reproducing
behavior


From: "Verma, Nitin (GEA, BLR, L529706)" <Nit...@ge...>
> Just leave mockobject for sec!
> [...]

I was going to respond this weekend, but you said everything I was going
to. Nice job.

Steve




_______________________________________________
Mockobjects-java-users mailing list
Moc...@li...
https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users


"THIS E-MAIL MESSAGE ALONG WITH ANY ATTACHMENTS IS INTENDED ONLY FOR THE
ADDRESSEE and may contain confidential and privileged information.
If the reader of this message is not the intended recipient,
you are notified that any dissemination, distribution or copy of this 
communication is strictly Prohibited. 
If you have received this message by error, please notify us 
immediately, return the original mail to the sender and delete the 
message from your system."

Re: [Mockobjects-java-users] simulating vs. reproducing behavior

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

From: "Verma, Nitin (GEA, BLR, L529706)" <Nit...@ge...>
> Just leave mockobject for sec!
> [...]

I was going to respond this weekend, but you said everything I was going
to. Nice job.

Steve

RE: [Mockobjects-java-users] simulating vs. reproducing behavior

[Verma, N. (G. B. L529706) <Nit...@ge...>]

Yups!

-----Original Message-----
From: Brian Denny [mailto:br...@dl...]
Sent: Friday, March 08, 2002 5:40 AM
To: Verma, Nitin (GEA, BLR, L529706)
Subject: Re: [Mockobjects-java-users] simulating vs. reproducing
behavior




so, all your updates will be done using an SQL query, rather than by using
an updatable result set, right?

-brian


> public abstract AbstarctSQLObject implements SQLObject{
>
>
> public final void execute throws SQLException{
>
> //excute code using getQuery()
> }
>
> public final void close(){
> //Code to close
> }
>
> protected abstract Striing getQuery();
>
> }



"THIS E-MAIL MESSAGE ALONG WITH ANY ATTACHMENTS IS INTENDED ONLY FOR THE
ADDRESSEE and may contain confidential and privileged information.
If the reader of this message is not the intended recipient,
you are notified that any dissemination, distribution or copy of this 
communication is strictly Prohibited. 
If you have received this message by error, please notify us 
immediately, return the original mail to the sender and delete the 
message from your system."

RE: [Mockobjects-java-users] simulating vs. reproducing behavior

[Verma, N. (G. B. L529706) <Nit...@ge...>]

DeleteSQLObject/InsertSQLObject/UpdateSQLObject extend...AbstarctSQLObject
sorry I missed

-----Original Message-----
From: Verma, Nitin (GEA, BLR, L529706) [mailto:Nit...@ge...]
Sent: Friday, March 08, 2002 4:57 AM
To: Brian Denny
Cc: moc...@li...
Subject: RE: [Mockobjects-java-users] simulating vs. reproducing
behavior




Just leave mockobject for sec!

	Can you access PreparedStatement/Statement of your SQLObject object?
	if not ... you can't rollback a transaction properly. You will
end-up having
	open cursors! (assert on to the closing of Statements)

I can smell duplication of code here!
------------
    	if (obj.isMarkedDeleted()) {
      	// jdbc code to delete obj from table
	} else if (obj.isMarkedChanged()) {
      	// jdbc code to update table row for obj
	} else if (obj.isMarkedNew()) {
      	// jdbck code to insert obj into table
	} else {
      	// do nothing
    	}
-----------

What I fell is you are making the query string in this util class.
I suggest you to make something like this:

public interface SQLObject{
	public void execute() throws SQLException;
	public void close() throws SQLException;
}

public class SQLObjectFactory{
	public static SQLObject getSQLObject(final String operation){
		// use an XML/properties file to get information on
SQLObjects
		// Like "insert=blah.blah.InsertSQLObject"
		SQLObject objSQLObject = SQLConfig.getSQLObject(operation);

		if(objSQLObject==null){
			return new NullSQLObject();
		}
		return objSQLObject;
	}	
}

public class NullSQLObject implements SQLObject{
	public void execute(){
		//do nothing
	}
	public void close(){
		//do nothing
	}

}

public abstract AbstarctSQLObject implements SQLObject{
	
	
	public final void execute throws SQLException{
		
		//excute code using getQuery()
	}

	public final void close(){
		//Code to close
	}
	
	protected abstract Striing getQuery();
	
}

public class DeleteSQLObject{
	protected  String getQuery() 
      	// code 
	}
}

public class InsertSQLObject{
	protected  String getQuery() 
      	// code 
	}
}

public class UpdateSQLObject{
	protected  String getQuery() 
      	// code 
	}
}

public class SQLObjectComposite{
	public void addSQLObject(SQLObject objSQLObject){
		//...
	}
	puclic SQLObjectIterator iterator(){
		//...
	}
	public void closeAll()throws SQLException{
		//...
	}
}

-----
public void update(Connection conn, SQLObjectComposite
objSQLObjectComposite) {
  SQLObjectIterator iterator = objSQLObjectComposite.iterator();
  (iterator.hasNext()) {
	try{
		iterator.next().excute();
		conn.commit();
	}
	catch(){
		conn.rollback();
	}
	finally{
		objSQLObjectComposite.closeAll();
		conn.close();
	}
  }
}
------
Now .. back to mack stuff:

Now u can assert for DeleteSQLObject/InsertSQLObject/UpdateSQLObject one by
one and 
assert for commit/rollback/close in your UpdateTest!

Comments?

Regards,

Nitin Verma
	 

-----Original Message-----
From: Brian Denny [mailto:br...@dl...]
Sent: Friday, March 08, 2002 3:52 AM
To: Verma, Nitin (GEA, BLR, L529706)
Cc: moc...@li...
Subject: Re: [Mockobjects-java-users] simulating vs. reproducing
behavior



perhaps i should give a more concrete example.

i have this utility method to stick a bunch of objects in a database.
each object corresponds to a table row and "knows" how to read/write itself
into a table.

// pseudojava
public void update(Connection conn, SQLObject[] objs) {
  for (each obj in objs) {
    if (obj.isMarkedDeleted()) {
      // jdbc code to delete obj from table
    } else if (obj.isMarkedChanged()) {
      // jdbc code to update table row for obj
    } else if (obj.isMarkedNew()) {
      // jdbck code to insert obj into table
    } else {
      // do nothing
    }
  }
}

now i want to test this method. so i write something like:

public void testUpdate throws Exception {
  // object declarations and creation snipped
  obj1.markNew();
  obj2.markChanged();
  obj3.markDeleted();
  mockStatement.setExpectedExecuteCalls(3);
  dbUtility.update(mockConnection, new SQLObject[] { obj1, obj2, obj3 });
  mockStatement.verify();
}

hmm.  the above doesn't actually test that i did one insert, one delete, and
one update.
so i could do the three updates separately -- one for each object -- and
test the query string each time:

public void testUpdate throws Exception {
  // object declarations and creation snipped
  obj1.markNew();
  obj2.markChanged();
  obj3.markDeleted();

  mockStatement.setExpectedExecuteCalls(1);
  mockStatement.setExpectedQueryString(
      "INSERT INTO objecttable values ('this is painful')");
  dbUtility.update(mockConnection, new SQLObject[] { obj1 });
  mockStatement.verify();

  mockStatement.setExpectedExecuteCalls(1);
  mockStatement.setExpectedQueryString("UPDATE objecttable set ...");
  dbUtility.update(mockConnection, new SQLObject[] { obj2 });
  mockStatement.verify();

  ... etc. ...
}

this is better, although now i'm not testing my ability to do all three at
once.

but now i decide to change my implementation of update() so that instead of
calling executeUpdate() on a Statement, it gets a ResultSet, and goes
through it updating and deleting and inserting rows as appropriate.

oops.  my tests just broke.

i'm not sure what to think about this.  since there is always more than one
way to do an update in JDBC, it seems to follow that there is no
implementation-INdependent way to test a method which is supposed to perform
some set of JDBC updates depending on the state of something-or-other, if
the only tools you have are tools that test which particular JDBC methods or
SQL queries you performed.

i don't see the point of writing implementation-dependent tests.  i want to
test the input-output behavior of my methods, not how they function.

comments?

-brian



"THIS E-MAIL MESSAGE ALONG WITH ANY ATTACHMENTS IS INTENDED ONLY FOR THE
ADDRESSEE and may contain confidential and privileged information.
If the reader of this message is not the intended recipient,
you are notified that any dissemination, distribution or copy of this 
communication is strictly Prohibited. 
If you have received this message by error, please notify us 
immediately, return the original mail to the sender and delete the 
message from your system."


_______________________________________________
Mockobjects-java-users mailing list
Moc...@li...
https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users


"THIS E-MAIL MESSAGE ALONG WITH ANY ATTACHMENTS IS INTENDED ONLY FOR THE
ADDRESSEE and may contain confidential and privileged information.
If the reader of this message is not the intended recipient,
you are notified that any dissemination, distribution or copy of this 
communication is strictly Prohibited. 
If you have received this message by error, please notify us 
immediately, return the original mail to the sender and delete the 
message from your system."

RE: [Mockobjects-java-users] simulating vs. reproducing behavior

[Verma, N. (G. B. L529706) <Nit...@ge...>]

Just leave mockobject for sec!

	Can you access PreparedStatement/Statement of your SQLObject object?
	if not ... you can't rollback a transaction properly. You will
end-up having
	open cursors! (assert on to the closing of Statements)

I can smell duplication of code here!
------------
    	if (obj.isMarkedDeleted()) {
      	// jdbc code to delete obj from table
	} else if (obj.isMarkedChanged()) {
      	// jdbc code to update table row for obj
	} else if (obj.isMarkedNew()) {
      	// jdbck code to insert obj into table
	} else {
      	// do nothing
    	}
-----------

What I fell is you are making the query string in this util class.
I suggest you to make something like this:

public interface SQLObject{
	public void execute() throws SQLException;
	public void close() throws SQLException;
}

public class SQLObjectFactory{
	public static SQLObject getSQLObject(final String operation){
		// use an XML/properties file to get information on
SQLObjects
		// Like "insert=blah.blah.InsertSQLObject"
		SQLObject objSQLObject = SQLConfig.getSQLObject(operation);

		if(objSQLObject==null){
			return new NullSQLObject();
		}
		return objSQLObject;
	}	
}

public class NullSQLObject implements SQLObject{
	public void execute(){
		//do nothing
	}
	public void close(){
		//do nothing
	}

}

public abstract AbstarctSQLObject implements SQLObject{
	
	
	public final void execute throws SQLException{
		
		//excute code using getQuery()
	}

	public final void close(){
		//Code to close
	}
	
	protected abstract Striing getQuery();
	
}

public class DeleteSQLObject{
	protected  String getQuery() 
      	// code 
	}
}

public class InsertSQLObject{
	protected  String getQuery() 
      	// code 
	}
}

public class UpdateSQLObject{
	protected  String getQuery() 
      	// code 
	}
}

public class SQLObjectComposite{
	public void addSQLObject(SQLObject objSQLObject){
		//...
	}
	puclic SQLObjectIterator iterator(){
		//...
	}
	public void closeAll()throws SQLException{
		//...
	}
}

-----
public void update(Connection conn, SQLObjectComposite
objSQLObjectComposite) {
  SQLObjectIterator iterator = objSQLObjectComposite.iterator();
  (iterator.hasNext()) {
	try{
		iterator.next().excute();
		conn.commit();
	}
	catch(){
		conn.rollback();
	}
	finally{
		objSQLObjectComposite.closeAll();
		conn.close();
	}
  }
}
------
Now .. back to mack stuff:

Now u can assert for DeleteSQLObject/InsertSQLObject/UpdateSQLObject one by
one and 
assert for commit/rollback/close in your UpdateTest!

Comments?

Regards,

Nitin Verma
	 

-----Original Message-----
From: Brian Denny [mailto:br...@dl...]
Sent: Friday, March 08, 2002 3:52 AM
To: Verma, Nitin (GEA, BLR, L529706)
Cc: moc...@li...
Subject: Re: [Mockobjects-java-users] simulating vs. reproducing
behavior



perhaps i should give a more concrete example.

i have this utility method to stick a bunch of objects in a database.
each object corresponds to a table row and "knows" how to read/write itself
into a table.

// pseudojava
public void update(Connection conn, SQLObject[] objs) {
  for (each obj in objs) {
    if (obj.isMarkedDeleted()) {
      // jdbc code to delete obj from table
    } else if (obj.isMarkedChanged()) {
      // jdbc code to update table row for obj
    } else if (obj.isMarkedNew()) {
      // jdbck code to insert obj into table
    } else {
      // do nothing
    }
  }
}

now i want to test this method. so i write something like:

public void testUpdate throws Exception {
  // object declarations and creation snipped
  obj1.markNew();
  obj2.markChanged();
  obj3.markDeleted();
  mockStatement.setExpectedExecuteCalls(3);
  dbUtility.update(mockConnection, new SQLObject[] { obj1, obj2, obj3 });
  mockStatement.verify();
}

hmm.  the above doesn't actually test that i did one insert, one delete, and
one update.
so i could do the three updates separately -- one for each object -- and
test the query string each time:

public void testUpdate throws Exception {
  // object declarations and creation snipped
  obj1.markNew();
  obj2.markChanged();
  obj3.markDeleted();

  mockStatement.setExpectedExecuteCalls(1);
  mockStatement.setExpectedQueryString(
      "INSERT INTO objecttable values ('this is painful')");
  dbUtility.update(mockConnection, new SQLObject[] { obj1 });
  mockStatement.verify();

  mockStatement.setExpectedExecuteCalls(1);
  mockStatement.setExpectedQueryString("UPDATE objecttable set ...");
  dbUtility.update(mockConnection, new SQLObject[] { obj2 });
  mockStatement.verify();

  ... etc. ...
}

this is better, although now i'm not testing my ability to do all three at
once.

but now i decide to change my implementation of update() so that instead of
calling executeUpdate() on a Statement, it gets a ResultSet, and goes
through it updating and deleting and inserting rows as appropriate.

oops.  my tests just broke.

i'm not sure what to think about this.  since there is always more than one
way to do an update in JDBC, it seems to follow that there is no
implementation-INdependent way to test a method which is supposed to perform
some set of JDBC updates depending on the state of something-or-other, if
the only tools you have are tools that test which particular JDBC methods or
SQL queries you performed.

i don't see the point of writing implementation-dependent tests.  i want to
test the input-output behavior of my methods, not how they function.

comments?

-brian



"THIS E-MAIL MESSAGE ALONG WITH ANY ATTACHMENTS IS INTENDED ONLY FOR THE
ADDRESSEE and may contain confidential and privileged information.
If the reader of this message is not the intended recipient,
you are notified that any dissemination, distribution or copy of this 
communication is strictly Prohibited. 
If you have received this message by error, please notify us 
immediately, return the original mail to the sender and delete the 
message from your system."

Re: [Mockobjects-java-users] simulating vs. reproducing behavior

[Brian D. <br...@dl...>]

perhaps i should give a more concrete example.

i have this utility method to stick a bunch of objects in a database.
each object corresponds to a table row and "knows" how to read/write itself
into a table.

// pseudojava
public void update(Connection conn, SQLObject[] objs) {
  for (each obj in objs) {
    if (obj.isMarkedDeleted()) {
      // jdbc code to delete obj from table
    } else if (obj.isMarkedChanged()) {
      // jdbc code to update table row for obj
    } else if (obj.isMarkedNew()) {
      // jdbck code to insert obj into table
    } else {
      // do nothing
    }
  }
}

now i want to test this method. so i write something like:

public void testUpdate throws Exception {
  // object declarations and creation snipped
  obj1.markNew();
  obj2.markChanged();
  obj3.markDeleted();
  mockStatement.setExpectedExecuteCalls(3);
  dbUtility.update(mockConnection, new SQLObject[] { obj1, obj2, obj3 });
  mockStatement.verify();
}

hmm.  the above doesn't actually test that i did one insert, one delete, and
one update.
so i could do the three updates separately -- one for each object -- and
test the query string each time:

public void testUpdate throws Exception {
  // object declarations and creation snipped
  obj1.markNew();
  obj2.markChanged();
  obj3.markDeleted();

  mockStatement.setExpectedExecuteCalls(1);
  mockStatement.setExpectedQueryString(
      "INSERT INTO objecttable values ('this is painful')");
  dbUtility.update(mockConnection, new SQLObject[] { obj1 });
  mockStatement.verify();

  mockStatement.setExpectedExecuteCalls(1);
  mockStatement.setExpectedQueryString("UPDATE objecttable set ...");
  dbUtility.update(mockConnection, new SQLObject[] { obj2 });
  mockStatement.verify();

  ... etc. ...
}

this is better, although now i'm not testing my ability to do all three at
once.

but now i decide to change my implementation of update() so that instead of
calling executeUpdate() on a Statement, it gets a ResultSet, and goes
through it updating and deleting and inserting rows as appropriate.

oops.  my tests just broke.

i'm not sure what to think about this.  since there is always more than one
way to do an update in JDBC, it seems to follow that there is no
implementation-INdependent way to test a method which is supposed to perform
some set of JDBC updates depending on the state of something-or-other, if
the only tools you have are tools that test which particular JDBC methods or
SQL queries you performed.

i don't see the point of writing implementation-dependent tests.  i want to
test the input-output behavior of my methods, not how they function.

comments?

-brian