mockobjects-java-dev

[MO-java-dev] ExpectationValue.getActual(), activity?

[Dmitri C. <col...@gm...>]

hey dev list,

I've been using mockobjects on and off where I've been able to wrestle
enough control over what I'm working on, and generally have been
pretty happy with the project.  However I'm finding that I'm starting
to need to extend things and would like to get a bit of a picture on
what's going on.  I notice that there are several patches outstanding,
and that the last release was in 2003, is anyone actively working on
mockobjects (I assume not)?  Is there anyone who will apply patches if
I submit them, or should I just keep my own copy of the build?

At the moment I'm working with the SQL package, and am finding that I
need to add more checks regarding SQL statements executed.  To do this
I want to increment the actual count when
PreparedStatement.executeQuery is called, but I cant do that at
present because there's no way (that I can see) of finding the current
count in ExpectationValue.  To get around this I've made my own copy
of ExpecationValue and added a getActual method and would like to
submit this (and a few other changes) back to the project. Anyone here
have any thoughts on it?

cheers
dim

Re: [MO-java-dev] ExpectationValue.getActual(), activity?

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

As a first step, you should consider moving to jmock, www.jmock,org,  
which is where we've been for a couple of weeks.

Can you send an example of one of your SQL tests?
S.

On 27 May 2005, at 02:20, Dmitri Colebatch wrote:
> hey dev list,
>
> I've been using mockobjects on and off where I've been able to wrestle
> enough control over what I'm working on, and generally have been
> pretty happy with the project.  However I'm finding that I'm starting
> to need to extend things and would like to get a bit of a picture on
> what's going on.  I notice that there are several patches outstanding,
> and that the last release was in 2003, is anyone actively working on
> mockobjects (I assume not)?  Is there anyone who will apply patches if
> I submit them, or should I just keep my own copy of the build?
>
> At the moment I'm working with the SQL package, and am finding that I
> need to add more checks regarding SQL statements executed.  To do this
> I want to increment the actual count when
> PreparedStatement.executeQuery is called, but I cant do that at
> present because there's no way (that I can see) of finding the current
> count in ExpectationValue.  To get around this I've made my own copy
> of ExpecationValue and added a getActual method and would like to
> submit this (and a few other changes) back to the project. Anyone here
> have any thoughts on it?
>
> cheers
> dim
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit  
> http://developer.yahoo.net/? 
> fr_______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>
>

Re: [MO-java-dev] ExpectationValue.getActual(), activity?

[Dmitri C. <col...@gm...>]

At this stage I'm really only using the java apis - I did look briefly
at jmock but it seemed more interested in allowing you to mock your
own apis, rather than supplying mocks of the java apis.  as we use
soap for pretty well any communication than spans system boundaries I
don't have that requirement.

I've attached the test that I'm working on atm.... would be interested
in some comments.

cheers
dim

On 5/27/05, Steve Freeman <st...@m3...> wrote:
> As a first step, you should consider moving to jmock, www.jmock,org,
> which is where we've been for a couple of weeks.
>=20
> Can you send an example of one of your SQL tests?
> S.
>=20
> On 27 May 2005, at 02:20, Dmitri Colebatch wrote:
> > hey dev list,
> >
> > I've been using mockobjects on and off where I've been able to wrestle
> > enough control over what I'm working on, and generally have been
> > pretty happy with the project.  However I'm finding that I'm starting
> > to need to extend things and would like to get a bit of a picture on
> > what's going on.  I notice that there are several patches outstanding,
> > and that the last release was in 2003, is anyone actively working on
> > mockobjects (I assume not)?  Is there anyone who will apply patches if
> > I submit them, or should I just keep my own copy of the build?
> >
> > At the moment I'm working with the SQL package, and am finding that I
> > need to add more checks regarding SQL statements executed.  To do this
> > I want to increment the actual count when
> > PreparedStatement.executeQuery is called, but I cant do that at
> > present because there's no way (that I can see) of finding the current
> > count in ExpectationValue.  To get around this I've made my own copy
> > of ExpecationValue and added a getActual method and would like to
> > submit this (and a few other changes) back to the project. Anyone here
> > have any thoughts on it?
> >
> > cheers
> > dim
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Yahoo.
> > Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> > Search APIs Find out how you can build Yahoo! directly into your own
> > Applications - visit
> > http://developer.yahoo.net/?
> > fr_______________________________________________
> > Mockobjects-java-dev mailing list
> > Moc...@li...
> > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> >
> >
>=20
>

Re: [MO-java-dev] ExpectationValue.getActual(), activity?

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

several points:
- the jdbc API is all interfaces, so I'd still suggest using jmock 
because it's easier to work with
- yes, the jmock library is largely about mocking your own interfaces, 
but there's a reason for that. The intention is to drive the design. At 
first glance, it looks like your code would benefit from being broken 
up into smaller objects, which can be tested individually. MO tests 
should be focussed and readable.
- if you want to test at this level, then it's more like a little 
integration test. Frankly, I'd think seriously about having little 
database and container instances to run against.
- What's all this mock container and aspect weaving about? If you want 
to use mocks, then write a domain layer that fits just insider the 
container and test that independently. Then all the container does is 
assemble the pieces and pass them through to the domain layer.
- Also consider a domain layer to manage persistence. This can be 
mocked out when testing the domain application code, and its real DB 
implementation tested separately.

S.


On 27 May 2005, at 08:14, Dmitri Colebatch wrote:
> At this stage I'm really only using the java apis - I did look briefly
> at jmock but it seemed more interested in allowing you to mock your
> own apis, rather than supplying mocks of the java apis.  as we use
> soap for pretty well any communication than spans system boundaries I
> don't have that requirement.
>
> I've attached the test that I'm working on atm.... would be interested
> in some comments.
>
> cheers
> dim
>
> On 5/27/05, Steve Freeman <st...@m3...> wrote:
>> As a first step, you should consider moving to jmock, www.jmock,org,
>> which is where we've been for a couple of weeks.
>>
>> Can you send an example of one of your SQL tests?
>> S.
>>
>> On 27 May 2005, at 02:20, Dmitri Colebatch wrote:
>>> hey dev list,
>>>
>>> I've been using mockobjects on and off where I've been able to 
>>> wrestle
>>> enough control over what I'm working on, and generally have been
>>> pretty happy with the project.  However I'm finding that I'm starting
>>> to need to extend things and would like to get a bit of a picture on
>>> what's going on.  I notice that there are several patches 
>>> outstanding,
>>> and that the last release was in 2003, is anyone actively working on
>>> mockobjects (I assume not)?  Is there anyone who will apply patches 
>>> if
>>> I submit them, or should I just keep my own copy of the build?
>>>
>>> At the moment I'm working with the SQL package, and am finding that I
>>> need to add more checks regarding SQL statements executed.  To do 
>>> this
>>> I want to increment the actual count when
>>> PreparedStatement.executeQuery is called, but I cant do that at
>>> present because there's no way (that I can see) of finding the 
>>> current
>>> count in ExpectationValue.  To get around this I've made my own copy
>>> of ExpecationValue and added a getActual method and would like to
>>> submit this (and a few other changes) back to the project. Anyone 
>>> here
>>> have any thoughts on it?

Re: [MO-java-dev] ExpectationValue.getActual(), activity?

[Dmitri C. <col...@gm...>]

Hi Steve,

Thanks for the feedback, criticism always welcome.  I hope you don't
mind me asking a few points though.

> - the jdbc API is all interfaces, so I'd still suggest using jmock
> because it's easier to work with

I'm not sure how this would change the structure of the test.  I'd
still be doing much the same as I am now yeah?

> - yes, the jmock library is largely about mocking your own interfaces,
> but there's a reason for that. The intention is to drive the design. At
> first glance, it looks like your code would benefit from being broken
> up into smaller objects, which can be tested individually. MO tests
> should be focussed and readable.

Yeah fair call, I've extracted the method out into a method object to
facilitate this, thanks for the heads up.  As an excuse I'm going to
state that I've just returned from a month long holiday (o:

> - if you want to test at this level, then it's more like a little
> integration test. Frankly, I'd think seriously about having little
> database and container instances to run against.

Yep, know what you're saying.  But I also wanted to do something
test-driven, and was stuck trying to think of where I should put a
test that made me write the code.

> - What's all this mock container and aspect weaving about? If you want
> to use mocks, then write a domain layer that fits just insider the
> container and test that independently. Then all the container does is
> assemble the pieces and pass them through to the domain layer.

I have no idea (o:  I just copied that from http://www.mockejb.org,
most of the setup method is from there.

> - Also consider a domain layer to manage persistence. This can be
> mocked out when testing the domain application code, and its real DB
> implementation tested separately.

Yeah, fighting that battle elsewhere (o:

cheers
dim

Re: [MO-java-dev] ExpectationValue.getActual(), activity?

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

Dmitri Colebatch wrote:
> Thanks for the feedback, criticism always welcome.  I hope you don't
> mind me asking a few points though.

of course.

>>- the jdbc API is all interfaces, so I'd still suggest using jmock
>>because it's easier to work with
> I'm not sure how this would change the structure of the test.  I'd
> still be doing much the same as I am now yeah?

yes, but I suspect you'd find the tests easier to work with. And, you 
can use less rigid constraints than just equals(), such as stringContains().

> Yeah fair call, I've extracted the method out into a method object to
> facilitate this, thanks for the heads up.  As an excuse I'm going to
> state that I've just returned from a month long holiday (o:

good start.

> Yep, know what you're saying.  But I also wanted to do something
> test-driven, and was stuck trying to think of where I should put a
> test that made me write the code.

then start much, much smaller and work your way up. Try writing little 
helper objects test-driven. That's part of the MO approach, use mocks to 
identify helper objects which you fill in later.

>>- What's all this mock container and aspect weaving about? If you want
>>  [...]
> I have no idea (o:  I just copied that from http://www.mockejb.org,
> most of the setup method is from there.

again. Start small and work your way up. If the tests have to be that 
complex, I'd rather find a fast container and run it in there.

>>- Also consider a domain layer to manage persistence. This can be
>>mocked out when testing the domain application code, and its real DB
>>implementation tested separately.
> Yeah, fighting that battle elsewhere (o:

good luck. Again, you might consider one of the O/R mapping frameworks. 
Just make sure you don't let the mapping code leak out into the domain code.

S.