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

[MO-java-dev] CVS: mockobjects-java/doc/xdocs/papers jdbc_testfirst.html,1.1,NONE

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

Update of /cvsroot/mockobjects/mockobjects-java/doc/xdocs/papers
In directory sc8-pr-cvs1:/tmp/cvs-serv5945/doc/xdocs/papers

Removed Files:
	jdbc_testfirst.html 
Log Message:
Moved content to the new wiki: http://wiki.truemesh.com/mockobjects/FrontPage. 

--- jdbc_testfirst.html DELETED ---

[MO-java-dev] CVS: mockobjects-java/doc/xdocs/misc mockobjects.pdf,1.1,NONE

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

Update of /cvsroot/mockobjects/mockobjects-java/doc/xdocs/misc
In directory sc8-pr-cvs1:/tmp/cvs-serv9948/doc/xdocs/misc

Removed Files:
	mockobjects.pdf 
Log Message:
Moved content to the new wiki: http://wiki.truemesh.com/mockobjects/FrontPage. 

--- mockobjects.pdf DELETED ---

[MO-java-dev] CVS: mockobjects-java/doc/xdocs/papers brief_introduction.html,1.4,NONE

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

Update of /cvsroot/mockobjects/mockobjects-java/doc/xdocs/papers
In directory sc8-pr-cvs1:/tmp/cvs-serv7998/doc/xdocs/papers

Removed Files:
	brief_introduction.html 
Log Message:
Removed duplicate file

--- brief_introduction.html DELETED ---

Re: [MO-java-dev] Why doesn't Mock check method parameter types as well as method names?

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

Tim Mackinnon wrote:

> Can you give a concrete example?
> 
> If you set the wrong expectations then I would expect a failure???

Sure:

public interface Foo {
     public void bar(Blob b, Goo g);
}

public void testFoo() {
     Blob expectedBlob = ...
     Mock mockFoo = new Mock();
     mockFoo.expectVoid("bar", new Constrant[]{C.eq(expectedBlob)});
         // The expectation is incorrect: There is no method "bar"
         // that takes just the Blob parameter. It would be nice if
         // the test failed immediatly at this point and indicated
         // a test setup error.

     SomethingThatUsesFoo s = new SomethingThatUsesFoo();
     s.useFoo(mockFoo);

     mockFoo.verify();
         // This verify will indeed fail, but it states that
         // "bar(Blob b)" did not get called. While this is true
         // it is misleading, as there is no such method, and
         // could never be called.
}


Does that make sense?

If the creation of the expectation checked that a method with the 
appropriate parameter types existed, then the test would fail much 
sooner, and provide much more direct feedback as to why the test failed. 
In addition, the error message would clearly indicated that  the problem 
is an issue of test setup not program correctness; maybe a simple 
mistake, or maybe a result of a refactoring.

For expect*() to be able to lookup the method, it would need to know the 
types of the parameters. But what it currently gets is Constraint's. 
Maybe Constraint could have a method such as getType() or 
getConstrainedClass(), which it obtains from the constructor argument. 
The IS_ANY would need to take a class argument I would think to make 
this work.

I brought this issue up a while ago on this list, but it was not really 
well received, or more likely I poorly described the issue. I suppose 
for smallish systems, these types of errors would not be too much 
trouble to fix after the test fails. But when you have 6000+ tests, a 
method refactoring on high-abstract/high-dependent class that 
invalidates mock setups could break hundreds of tests.

This was on of the benefits of EasyMock -- it used the actual typed 
interface for setting up expectations. But at the huge cost of no 
Constraints. I would prefer compile-time failure when expectations 
reference a non-existant method, but see no way to do that other then 
with some type of introspection on the class files.

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

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

> The branch is very stable - and we will be moving to it asap. I think it
> addresses many of your issues.

Great. Does a summary of the changes exist anywhere?

Re: [MO-java-dev] [New DynaMock] expectNotCalled deprecated, why?

[Joe W. <jo...@tr...>]

I like that method too. Particularly as I often have an expectation 
setup for a method in setUp which I later want to override for a 
specific test.

Can we get it back?

-j


Vincent Massol wrote:

>Actually, I've understood the comment now but I still think this method
>should not be deprecated as it explains what the test is trying to do.
>With no method, you'll need to either document the test or hope that the
>reader will understand it...
>
>What do you think?
>
>Thanks
>-Vincent
>
>  
>
>>-----Original Message-----
>>From: moc...@li...
>>[mailto:moc...@li...] On Behalf Of
>>Vincent Massol
>>Sent: 16 May 2003 09:30
>>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
>>    
>>
>
>
>
>-------------------------------------------------------
>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] [new dyna mock] Bug?

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

Guys,

I need your help! I've been trying to migrate my existing project to the
new Dyna Mock for the past few days and I'm stuck...

The tests I am trying to migrate are located here: 

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/junitbook/junitbook/ejb/m
ockobjects/

If you are working with Eclipse, the easiest it to import first the
repository/ project
(http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/junitbook/junitbook/repo
sitory/) in your workspace, rename it to junitbook-repository (it is
imported with the name "repository" by default) and then import the
ejb/mockobjects project
(http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/junitbook/junitbook/ejb/
mockobjects/).

(these projects are already Eclipse projects)

The CVS information is available on
http://sourceforge.net/cvs/?group_id=68011

The tests to look at in priority are:
- junitbook.ejb.service3.TestPetstoreEJB
- junitbook.ejb.domain.TestOrderUtil

The 2 tests demonstrate the issue I have been describing below.

Thanks a bunch
-Vincent

> > -----Original Message-----
> > From: Tim Mackinnon [mailto:tim...@po...]
> > Sent: 16 May 2003 02:02
> > To: Vincent Massol
> > Subject: RE: [MO-java-dev] [new dyna mock] Bug?
> >
> > Hmmm thats weird? There is no specific test for that as we assume
that
> > junit
> > has independant tests, and there is no global state in the dynamic
> stuff
> > (it
> > folds with the test). The library has also been used quite a bit by
> the
> > e2x
> > guys who have lots of concurrent tests....and not reported this one.
> >
> > If you can help by debugging or creating a test we can have look.
> >
> > Tim
> >
> >
> > > -----Original Message-----
> > > From: moc...@li...
> > > [mailto:moc...@li...]On Behalf
> Of
> > > Vincent Massol
> > > Sent: 15 May 2003 10:08
> > > To: 'Mockobjects-Java-Dev'
> > > Subject: [MO-java-dev] [new dyna mock] Bug?
> > >
> > >
> > > Hi,
> > >
> > > I have the following 2 tests:
> > >
> > >     public void testCreateOrderOk() throws Exception
> > >     {
> > >         mockQueueConnectionFactory.expectAndReturn(
> > >             "createQueueConnection", queueConnection);
> > >
> > >         int orderId = petstore.createOrder(new Date(), "item1");
> > >
> > >         assertEquals(1234, orderId);
> > >     }
> > >
> > >     public void testCreateThrowsOrderException() throws Exception
> > >     {
> > >         mockQueueConnectionFactory.expectAndThrow(
> > >             "createQueueConnection", new JMSException("error"));
> > >
> > >         try
> > >         {
> > >             petstore.createOrder(new Date(), "item1");
> > >             fail("Should have thrown an EJBException");
> > >         }
> > >         catch (EJBException expected)
> > >         {
> > >             assertEquals("error",
> > >                 expected.getCausedByException().getMessage());
> > >         }
> > >     }
> > >
> > > The second test (testCreateThrowsOrderException()) fails with the
> > > following error:
> > >
> > > junit.framework.AssertionFailedError: mockQueueConnectionFactory:
> > > Unexpected call: createQueueConnection()
> > > Expected one of:
> > > createQueueConnection() [called]
> > > [...]
> > >
> > > If I comment out the testCreateOrderOk() method it works...
> > >
> > > It seems that the 2 tests are overstepping each other and that the
> > > second mock expectAndThrow() is not taken into account because the
> mock
> > > has already been set up by the first test! Glurps....
> > >
> > > Any idea? Do we have a test case for this scenario in our test
> suite?
> > >
> > > 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
> > >
> > > ---
> > > Incoming mail is certified Virus Free.
> > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
> > >
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
> 
> 
> 
> 
> -------------------------------------------------------
> 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] [New DynaMock] expectNotCalled deprecated, why?

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

Actually, I've understood the comment now but I still think this method
should not be deprecated as it explains what the test is trying to do.
With no method, you'll need to either document the test or hope that the
reader will understand it...

What do you think?

Thanks
-Vincent

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...] On Behalf Of
> Vincent Massol
> Sent: 16 May 2003 09:30
> 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

[MO-java-dev] [New DynaMock] expectNotCalled deprecated, why?

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

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

RE: [MO-java-dev] [New DynaMock] Why is there no match() method?

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

> > -----Original Message-----
> > From: Tim Mackinnon [mailto:tim...@po...]
> > Sent: 16 May 2003 01:36
> > To: Vincent Massol
> > Subject: RE: [MO-java-dev] [New DynaMock] Why is there no match()
> method?
> >
> > Now you are on to something!
> >
> > For methods with no return type - do we want a mock type that
doesn't
> > care?
> > (If there is a return type I think its dangerous to provide a
default
> > value
> > as this smells of missing tests - and a lack of documentation via a
> test.)
> > -
> > however void methods are interesting. Should you have to be
specific?
> >
> > I am warming to the idea of match(...) (its kind of an ignore() but
> that
> > introduces another name so match() seems good). If you did this in
> setUp,
> > then if you really care you put an expect in a test which would take
> > precendence. I like this behaviour - I've seen this before, you
> shouldn't
> > get hosed for having defaults in a setUp method but can be more
> precise
> > when
> > you want to.
> >
> > You could add this vincent - its pretty straightforward. I would
> suggest
> > also augmenting the SimpleServletTest to show this - as its our
> functional
> > test at the moment.

An interesting suggestion but I'd prefer if it is someone who has been
involved in writing the new DynaMock who does it. I'm starving for time
right now (I shouldn't even have enough time to get involved in the
mockobjects project at all :-)).

This I greatly appreciate if one of you could add this... I've added it
as a feature request in SF:
https://sourceforge.net/tracker/index.php?func=detail&aid=738667&group_i
d=18189&atid=368189

Thanks
-Vincent

> >
> > Tim
> >
> > > -----Original Message-----
> > > From: moc...@li...
> > > [mailto:moc...@li...]On Behalf
> Of
> > > Vincent Massol
> > > Sent: 15 May 2003 09:45
> > > To: 'Joe Walnes'
> > > Cc: moc...@li...
> > > Subject: RE: [MO-java-dev] [New DynaMock] Why is there no match()
> > > method?
> > >
> > >
> > > Ok. Here's use case:
> > >
> > > I have in my code a call to queueConnection.close() (for example).
I
> use
> > > a Mock for QueueConnection. If I *don't* define either an
expect*()
> or a
> > > match*(), I get:
> > >
> > > junit.framework.AssertionFailedError: mockQueueConnection:
> Unexpected
> > > call: close()
> > > Expected no methods
> > > 	at com.mockobjects.dynamic.Mock.invoke(Mock.java:95)
> > > [...]
> > >
> > > Which means to me that we have to define the behaviour for any
> method
> > > called (and that there is no default behaviour assumed). Fine with
> me.
> > > Then, I don't want to set an expectation on close() because this
> mock
> > > setup is part of a general setup that I want to reuse across
several
> > > tests and some tests do call close(), some do not.
> > >
> > > But there is no match() method.
> > >
> > > Basically I'd like to simply tell DynaMock that I don't care about
> this
> > > close() method. ATM, I've tricked it, by using:
> > >
> > >         mockQueueConnection.matchAndReturn("close", null);
> > >
> > > But that seems like a hack (or even a DynaMock bug) to me.
> > >
> > > Am I not thinking in the right direction?
> > >
> > > Thanks
> > > -Vincent
> > >
> > > > -----Original Message-----
> > > > From: Joe Walnes [mailto:jo...@tr...]
> > > > Sent: 15 May 2003 09:03
> > > > To: Vincent Massol
> > > > Cc: moc...@li...
> > > > Subject: Re: [MO-java-dev] [New DynaMock] Why is there no
match()
> > > method?
> > > >
> > > > That's right. There's no reason to use match if you're not
trying
> to
> > > > setup a return value. You can still use expect in the same way
to
> > > setup
> > > > return values which also have expectations on the method calls.
> > > >
> > > > Vincent Massol wrote:
> > > >
> > > > >Hi Joe,
> > > > >
> > > > >I thought the only difference between match*() and expect*()
was
> that
> > > > >expected methods were setting expectations that were verified
> when
> > > you
> > > > >call the verify() method on the mock?
> > > > >
> > > > >Also, expectAndReturn() does also setup return values, right?
> > > > >
> > > > >Thanks
> > > > >-Vincent (Still confused by the difference between match*() and
> > > > >expect*() :-))
> > > > >
> > > > >
> > > > >
> > > > >>-----Original Message-----
> > > > >>From: Joe Walnes [mailto:jo...@tr...]
> > > > >>Sent: 14 May 2003 21:38
> > > > >>To: Vincent Massol; moc...@li...
> > > > >>Subject: Re: [MO-java-dev] [New DynaMock] Why is there no
> match()
> > > > >>
> > > > >>
> > > > >method?
> > > > >
> > > > >
> > > > >>Vincent Massol wrote:
> > > > >>
> > > > >>
> > > > >>
> > > > >>>Hi,
> > > > >>>
> > > > >>>There is an expect() method (replacing the old expectVoid()),
> but
> > > > >>>
> > > > >>>
> > > > >there
> > > > >
> > > > >
> > > > >>>is no match() method. Any reason?
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>The only use of match() is to setup return values - so it's
not
> > > needed
> > > > >>for void methods.
> > > > >>
> > > > >>-joe
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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
> > >
> > > ---
> > > Incoming mail is certified Virus Free.
> > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
> > >
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
> 
> 
> 
> 
> -------------------------------------------------------
> 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

FW: [MO-java-dev] [new dyna mock] Bug?

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

FYI

> -----Original Message-----
> From: Tim Mackinnon [mailto:tim...@po...]
> Sent: 16 May 2003 02:02
> To: Vincent Massol
> Subject: RE: [MO-java-dev] [new dyna mock] Bug?
> 
> Hmmm thats weird? There is no specific test for that as we assume that
> junit
> has independant tests, and there is no global state in the dynamic
stuff
> (it
> folds with the test). The library has also been used quite a bit by
the
> e2x
> guys who have lots of concurrent tests....and not reported this one.
> 
> If you can help by debugging or creating a test we can have look.
> 
> Tim
> 
> 
> > -----Original Message-----
> > From: moc...@li...
> > [mailto:moc...@li...]On Behalf
Of
> > Vincent Massol
> > Sent: 15 May 2003 10:08
> > To: 'Mockobjects-Java-Dev'
> > Subject: [MO-java-dev] [new dyna mock] Bug?
> >
> >
> > Hi,
> >
> > I have the following 2 tests:
> >
> >     public void testCreateOrderOk() throws Exception
> >     {
> >         mockQueueConnectionFactory.expectAndReturn(
> >             "createQueueConnection", queueConnection);
> >
> >         int orderId = petstore.createOrder(new Date(), "item1");
> >
> >         assertEquals(1234, orderId);
> >     }
> >
> >     public void testCreateThrowsOrderException() throws Exception
> >     {
> >         mockQueueConnectionFactory.expectAndThrow(
> >             "createQueueConnection", new JMSException("error"));
> >
> >         try
> >         {
> >             petstore.createOrder(new Date(), "item1");
> >             fail("Should have thrown an EJBException");
> >         }
> >         catch (EJBException expected)
> >         {
> >             assertEquals("error",
> >                 expected.getCausedByException().getMessage());
> >         }
> >     }
> >
> > The second test (testCreateThrowsOrderException()) fails with the
> > following error:
> >
> > junit.framework.AssertionFailedError: mockQueueConnectionFactory:
> > Unexpected call: createQueueConnection()
> > Expected one of:
> > createQueueConnection() [called]
> > [...]
> >
> > If I comment out the testCreateOrderOk() method it works...
> >
> > It seems that the 2 tests are overstepping each other and that the
> > second mock expectAndThrow() is not taken into account because the
mock
> > has already been set up by the first test! Glurps....
> >
> > Any idea? Do we have a test case for this scenario in our test
suite?
> >
> > 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
> >
> > ---
> > Incoming mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
> >
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003

FW: [MO-java-dev] [New DynaMock] Why is there no match() method?

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

Forwarded to the list as it may interest others too.
-Vincent

> -----Original Message-----
> From: Tim Mackinnon [mailto:tim...@po...]
> Sent: 16 May 2003 01:36
> To: Vincent Massol
> Subject: RE: [MO-java-dev] [New DynaMock] Why is there no match()
method?
> 
> Now you are on to something!
> 
> For methods with no return type - do we want a mock type that doesn't
> care?
> (If there is a return type I think its dangerous to provide a default
> value
> as this smells of missing tests - and a lack of documentation via a
test.)
> -
> however void methods are interesting. Should you have to be specific?
> 
> I am warming to the idea of match(...) (its kind of an ignore() but
that
> introduces another name so match() seems good). If you did this in
setUp,
> then if you really care you put an expect in a test which would take
> precendence. I like this behaviour - I've seen this before, you
shouldn't
> get hosed for having defaults in a setUp method but can be more
precise
> when
> you want to.
> 
> You could add this vincent - its pretty straightforward. I would
suggest
> also augmenting the SimpleServletTest to show this - as its our
functional
> test at the moment.
> 
> Tim
> 
> > -----Original Message-----
> > From: moc...@li...
> > [mailto:moc...@li...]On Behalf
Of
> > Vincent Massol
> > Sent: 15 May 2003 09:45
> > To: 'Joe Walnes'
> > Cc: moc...@li...
> > Subject: RE: [MO-java-dev] [New DynaMock] Why is there no match()
> > method?
> >
> >
> > Ok. Here's use case:
> >
> > I have in my code a call to queueConnection.close() (for example). I
use
> > a Mock for QueueConnection. If I *don't* define either an expect*()
or a
> > match*(), I get:
> >
> > junit.framework.AssertionFailedError: mockQueueConnection:
Unexpected
> > call: close()
> > Expected no methods
> > 	at com.mockobjects.dynamic.Mock.invoke(Mock.java:95)
> > [...]
> >
> > Which means to me that we have to define the behaviour for any
method
> > called (and that there is no default behaviour assumed). Fine with
me.
> > Then, I don't want to set an expectation on close() because this
mock
> > setup is part of a general setup that I want to reuse across several
> > tests and some tests do call close(), some do not.
> >
> > But there is no match() method.
> >
> > Basically I'd like to simply tell DynaMock that I don't care about
this
> > close() method. ATM, I've tricked it, by using:
> >
> >         mockQueueConnection.matchAndReturn("close", null);
> >
> > But that seems like a hack (or even a DynaMock bug) to me.
> >
> > Am I not thinking in the right direction?
> >
> > Thanks
> > -Vincent
> >
> > > -----Original Message-----
> > > From: Joe Walnes [mailto:jo...@tr...]
> > > Sent: 15 May 2003 09:03
> > > To: Vincent Massol
> > > Cc: moc...@li...
> > > Subject: Re: [MO-java-dev] [New DynaMock] Why is there no match()
> > method?
> > >
> > > That's right. There's no reason to use match if you're not trying
to
> > > setup a return value. You can still use expect in the same way to
> > setup
> > > return values which also have expectations on the method calls.
> > >
> > > Vincent Massol wrote:
> > >
> > > >Hi Joe,
> > > >
> > > >I thought the only difference between match*() and expect*() was
that
> > > >expected methods were setting expectations that were verified
when
> > you
> > > >call the verify() method on the mock?
> > > >
> > > >Also, expectAndReturn() does also setup return values, right?
> > > >
> > > >Thanks
> > > >-Vincent (Still confused by the difference between match*() and
> > > >expect*() :-))
> > > >
> > > >
> > > >
> > > >>-----Original Message-----
> > > >>From: Joe Walnes [mailto:jo...@tr...]
> > > >>Sent: 14 May 2003 21:38
> > > >>To: Vincent Massol; moc...@li...
> > > >>Subject: Re: [MO-java-dev] [New DynaMock] Why is there no
match()
> > > >>
> > > >>
> > > >method?
> > > >
> > > >
> > > >>Vincent Massol wrote:
> > > >>
> > > >>
> > > >>
> > > >>>Hi,
> > > >>>
> > > >>>There is an expect() method (replacing the old expectVoid()),
but
> > > >>>
> > > >>>
> > > >there
> > > >
> > > >
> > > >>>is no match() method. Any reason?
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>The only use of match() is to setup return values - so it's not
> > needed
> > > >>for void methods.
> > > >>
> > > >>-joe
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
> >
> > ---
> > Incoming mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
> >
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003

FW: [MO-java-dev] [New DynaMock] Why is there no match() method?

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

Forwarded to the list as it may interest others too.
-Vincent

> -----Original Message-----
> From: Tim Mackinnon [mailto:tim...@po...]
> Sent: 16 May 2003 01:36
> To: Vincent Massol
> Subject: RE: [MO-java-dev] [New DynaMock] Why is there no match()
method?
> 
> Now you are on to something!
> 
> For methods with no return type - do we want a mock type that doesn't
> care?
> (If there is a return type I think its dangerous to provide a default
> value
> as this smells of missing tests - and a lack of documentation via a
test.)
> -
> however void methods are interesting. Should you have to be specific?
> 
> I am warming to the idea of match(...) (its kind of an ignore() but
that
> introduces another name so match() seems good). If you did this in
setUp,
> then if you really care you put an expect in a test which would take
> precendence. I like this behaviour - I've seen this before, you
shouldn't
> get hosed for having defaults in a setUp method but can be more
precise
> when
> you want to.
> 
> You could add this vincent - its pretty straightforward. I would
suggest
> also augmenting the SimpleServletTest to show this - as its our
functional
> test at the moment.
> 
> Tim
> 
> > -----Original Message-----
> > From: moc...@li...
> > [mailto:moc...@li...]On Behalf
Of
> > Vincent Massol
> > Sent: 15 May 2003 09:45
> > To: 'Joe Walnes'
> > Cc: moc...@li...
> > Subject: RE: [MO-java-dev] [New DynaMock] Why is there no match()
> > method?
> >
> >
> > Ok. Here's use case:
> >
> > I have in my code a call to queueConnection.close() (for example). I
use
> > a Mock for QueueConnection. If I *don't* define either an expect*()
or a
> > match*(), I get:
> >
> > junit.framework.AssertionFailedError: mockQueueConnection:
Unexpected
> > call: close()
> > Expected no methods
> > 	at com.mockobjects.dynamic.Mock.invoke(Mock.java:95)
> > [...]
> >
> > Which means to me that we have to define the behaviour for any
method
> > called (and that there is no default behaviour assumed). Fine with
me.
> > Then, I don't want to set an expectation on close() because this
mock
> > setup is part of a general setup that I want to reuse across several
> > tests and some tests do call close(), some do not.
> >
> > But there is no match() method.
> >
> > Basically I'd like to simply tell DynaMock that I don't care about
this
> > close() method. ATM, I've tricked it, by using:
> >
> >         mockQueueConnection.matchAndReturn("close", null);
> >
> > But that seems like a hack (or even a DynaMock bug) to me.
> >
> > Am I not thinking in the right direction?
> >
> > Thanks
> > -Vincent
> >
> > > -----Original Message-----
> > > From: Joe Walnes [mailto:jo...@tr...]
> > > Sent: 15 May 2003 09:03
> > > To: Vincent Massol
> > > Cc: moc...@li...
> > > Subject: Re: [MO-java-dev] [New DynaMock] Why is there no match()
> > method?
> > >
> > > That's right. There's no reason to use match if you're not trying
to
> > > setup a return value. You can still use expect in the same way to
> > setup
> > > return values which also have expectations on the method calls.
> > >
> > > Vincent Massol wrote:
> > >
> > > >Hi Joe,
> > > >
> > > >I thought the only difference between match*() and expect*() was
that
> > > >expected methods were setting expectations that were verified
when
> > you
> > > >call the verify() method on the mock?
> > > >
> > > >Also, expectAndReturn() does also setup return values, right?
> > > >
> > > >Thanks
> > > >-Vincent (Still confused by the difference between match*() and
> > > >expect*() :-))
> > > >
> > > >
> > > >
> > > >>-----Original Message-----
> > > >>From: Joe Walnes [mailto:jo...@tr...]
> > > >>Sent: 14 May 2003 21:38
> > > >>To: Vincent Massol; moc...@li...
> > > >>Subject: Re: [MO-java-dev] [New DynaMock] Why is there no
match()
> > > >>
> > > >>
> > > >method?
> > > >
> > > >
> > > >>Vincent Massol wrote:
> > > >>
> > > >>
> > > >>
> > > >>>Hi,
> > > >>>
> > > >>>There is an expect() method (replacing the old expectVoid()),
but
> > > >>>
> > > >>>
> > > >there
> > > >
> > > >
> > > >>>is no match() method. Any reason?
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>The only use of match() is to setup return values - so it's not
> > needed
> > > >>for void methods.
> > > >>
> > > >>-joe
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
> >
> > ---
> > Incoming mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
> >
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003

[MO-java-dev] [status] Move to wiki

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

Hi,

I've started moving our docs to the wiki
(http://wiki.truemesh.com/mockobjects/FrontPage). It's almost done. We
still need to move the 2 papers in docs/xdocs/papers.

If someone could do that would be great (I'm too tired right now :-)).

Thanks
-Vincent

[MO-java-dev] CVS: mockobjects-java/doc README,NONE,1.1 .cvsignore,1.1,NONE site.xml,1.9,NONE

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

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

Added Files:
	README 
Removed Files:
	.cvsignore site.xml 
Log Message:
Moved content to the new wiki: http://wiki.truemesh.com/mockobjects/FrontPage. 

--- NEW FILE: README ---
All documentation has been moved to the MockObjects wiki: http://wiki.truemesh.com/mockobjects/FrontPage

--- .cvsignore DELETED ---

--- site.xml DELETED ---

[MO-java-dev] CVS: mockobjects-java/doc/xdocs/images add.jpg,1.1,NONE fix.jpg,1.1,NONE remove.jpg,1.1,NONE update.jpg,1.1,NONE

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

Update of /cvsroot/mockobjects/mockobjects-java/doc/xdocs/images
In directory sc8-pr-cvs1:/tmp/cvs-serv24505/doc/xdocs/images

Removed Files:
	add.jpg fix.jpg remove.jpg update.jpg 
Log Message:
Moved content to the new wiki: http://wiki.truemesh.com/mockobjects/FrontPage. 

--- add.jpg DELETED ---

--- fix.jpg DELETED ---

--- remove.jpg DELETED ---

--- update.jpg DELETED ---

[MO-java-dev] CVS: mockobjects-java/doc/xdocs/dtd changes-v10.dtd,1.2,NONE characters.ent,1.1,NONE document-v10.dtd,1.1,NONE todo-v10.dtd,1.1,NONE

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

Update of /cvsroot/mockobjects/mockobjects-java/doc/xdocs/dtd
In directory sc8-pr-cvs1:/tmp/cvs-serv24505/doc/xdocs/dtd

Removed Files:
	changes-v10.dtd characters.ent document-v10.dtd todo-v10.dtd 
Log Message:
Moved content to the new wiki: http://wiki.truemesh.com/mockobjects/FrontPage. 

--- changes-v10.dtd DELETED ---

--- characters.ent DELETED ---

--- document-v10.dtd DELETED ---

--- todo-v10.dtd DELETED ---

[MO-java-dev] CVS: mockobjects-java/doc/xdocs changes.xml,1.4,NONE coding_conventions.xml,1.6,NONE doc-book.xml,1.10,NONE downloads.xml,1.1,NONE endotesting.xml,1.2,NONE index.xml,1.15,NONE license.xml,1.1,NONE naming_conventions.xml,1.1,NONE papers.xml,1.4,NONE release_process.xml,1.2,NONE site-book.xml,1.9,NONE todo.xml,1.7,NONE

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

Update of /cvsroot/mockobjects/mockobjects-java/doc/xdocs
In directory sc8-pr-cvs1:/tmp/cvs-serv24505/doc/xdocs

Removed Files:
	changes.xml coding_conventions.xml doc-book.xml downloads.xml 
	endotesting.xml index.xml license.xml naming_conventions.xml 
	papers.xml release_process.xml site-book.xml todo.xml 
Log Message:
Moved content to the new wiki: http://wiki.truemesh.com/mockobjects/FrontPage. 

--- changes.xml DELETED ---

--- coding_conventions.xml DELETED ---

--- doc-book.xml DELETED ---

--- downloads.xml DELETED ---

--- endotesting.xml DELETED ---

--- index.xml DELETED ---

--- license.xml DELETED ---

--- naming_conventions.xml DELETED ---

--- papers.xml DELETED ---

--- release_process.xml DELETED ---

--- site-book.xml DELETED ---

--- todo.xml DELETED ---

[MO-java-dev] CVS: mockobjects-java/doc/skins/jakarta.apache.org/stylesheets book2project.xsl,1.2,NONE changes2document.xsl,1.2,NONE copyover.xsl,1.1,NONE document2html.xsl,1.5,NONE roadmap2document.xsl,1.1,NONE todo2document.xsl,1.1,NONE

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

Update of /cvsroot/mockobjects/mockobjects-java/doc/skins/jakarta.apache.org/stylesheets
In directory sc8-pr-cvs1:/tmp/cvs-serv24505/doc/skins/jakarta.apache.org/stylesheets

Removed Files:
	book2project.xsl changes2document.xsl copyover.xsl 
	document2html.xsl roadmap2document.xsl todo2document.xsl 
Log Message:
Moved content to the new wiki: http://wiki.truemesh.com/mockobjects/FrontPage. 

--- book2project.xsl DELETED ---

--- changes2document.xsl DELETED ---

--- copyover.xsl DELETED ---

--- document2html.xsl DELETED ---

--- roadmap2document.xsl DELETED ---

--- todo2document.xsl DELETED ---

[MO-java-dev] CVS: mockobjects-java/doc/skins/jakarta.apache.org/resources add.jpg,1.1,NONE fix.jpg,1.1,NONE jakarta-logo.gif,1.1,NONE mockobjects.gif,1.1,NONE mockturtle.jpg,1.3,NONE note.gif,1.1,NONE remove.jpg,1.1,NONE update.jpg,1.1,NONE

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

Update of /cvsroot/mockobjects/mockobjects-java/doc/skins/jakarta.apache.org/resources
In directory sc8-pr-cvs1:/tmp/cvs-serv24505/doc/skins/jakarta.apache.org/resources

Removed Files:
	add.jpg fix.jpg jakarta-logo.gif mockobjects.gif 
	mockturtle.jpg note.gif remove.jpg update.jpg 
Log Message:
Moved content to the new wiki: http://wiki.truemesh.com/mockobjects/FrontPage. 

--- add.jpg DELETED ---

--- fix.jpg DELETED ---

--- jakarta-logo.gif DELETED ---

--- mockobjects.gif DELETED ---

--- mockturtle.jpg DELETED ---

--- note.gif DELETED ---

--- remove.jpg DELETED ---

--- update.jpg DELETED ---

[MO-java-dev] CVS: mockobjects-java/doc/skins/jakarta.apache.org loader.xml,1.1,NONE

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

Update of /cvsroot/mockobjects/mockobjects-java/doc/skins/jakarta.apache.org
In directory sc8-pr-cvs1:/tmp/cvs-serv24505/doc/skins/jakarta.apache.org

Removed Files:
	loader.xml 
Log Message:
Moved content to the new wiki: http://wiki.truemesh.com/mockobjects/FrontPage. 

--- loader.xml DELETED ---

[MO-java-dev] CVS: mockobjects-java/doc/html alt.html,1.1,NONE changes.html,1.3,NONE coding_conventions.html,1.3,NONE downloads.html,1.1,NONE endotesting.html,1.1,NONE faq.html,1.5,NONE index.html,1.4,NONE license.html,1.2,NONE naming_conventions.html,1.2,NONE papers.html,1.2,NONE release_process.html,1.2,NONE stylesheet.css,1.3,NONE template.txt,1.8,NONE todo.html,1.3,NONE

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

Update of /cvsroot/mockobjects/mockobjects-java/doc/html
In directory sc8-pr-cvs1:/tmp/cvs-serv24505/doc/html

Removed Files:
	alt.html changes.html coding_conventions.html downloads.html 
	endotesting.html faq.html index.html license.html 
	naming_conventions.html papers.html release_process.html 
	stylesheet.css template.txt todo.html 
Log Message:
Moved content to the new wiki: http://wiki.truemesh.com/mockobjects/FrontPage. 

--- alt.html DELETED ---

--- changes.html DELETED ---

--- coding_conventions.html DELETED ---

--- downloads.html DELETED ---

--- endotesting.html DELETED ---

--- faq.html DELETED ---

--- index.html DELETED ---

--- license.html DELETED ---

--- naming_conventions.html DELETED ---

--- papers.html DELETED ---

--- release_process.html DELETED ---

--- stylesheet.css DELETED ---

--- template.txt DELETED ---

--- todo.html DELETED ---

[MO-java-dev] CVS: mockobjects-java/doc/com/mockobjects/doc SiteTemplate.java,1.2,NONE

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

Update of /cvsroot/mockobjects/mockobjects-java/doc/com/mockobjects/doc
In directory sc8-pr-cvs1:/tmp/cvs-serv24505/doc/com/mockobjects/doc

Removed Files:
	SiteTemplate.java 
Log Message:
Moved content to the new wiki: http://wiki.truemesh.com/mockobjects/FrontPage. 

--- SiteTemplate.java DELETED ---

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

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

Tim Mackinnon wrote:

> Actually if its just for getters and you just want to specify a return value
> (and not bother setting an expectation, just use matchAndReturn). Or use
> both to get an initial expectation and then a default (and then no need for
> a special factory)
> 
> expectAndReturn("getX", 5);
> matchAndReturn("getX", 5);

Now I'm confused. I see no method matchAndReturn(). Is that only in the 
branch?

[MO-java-dev] Wiki and Stylebook... not too different after all...

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

Hey, this is really funny! If you go to our wiki
(http://wiki.truemesh.com/mockobjects/FrontPage) and click on the XML
icom to display the page as XML (the button is located in top right
corner), you'll get an error with IE. Hold on, that's not the funny
stuff yet!

Now, click on "view source" and you'll see the XML. Does it sound
familiar?

Yep, you're right! It uses the Stylebook DTD, i.e. the one we were using
when we had the docs in xdocs format :-)

Funny, no?

-Vincent