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

Re: [MO-java-dev] Javadoc is now online...

[Nat P. <nat...@b1...>]

From: "Tim Mackinnon" <tim...@po...>
> Really interestingly, one of the Thoughtworks teams finally took a long
> standing idea and generated docs for a class where they parsed the test
> names for a class and outputed:
> 
> ClassX is an object that:
> - Handles Zero Items Added
> - Handles N Items With a Null
> - Throw An Exception With An Empty List
> - Allows Mixed Object Addition
> etc.

What a great idea! Are there any plans to release this tool?

Cheers,
            Nat.

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

RE: [MO-java-dev] Javadoc is now online...

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

> -----Original Message-----
> From: Tim Mackinnon [mailto:tim...@po...]
> Sent: 06 June 2003 02:32
> To: Vincent Massol; moc...@li...
> Cc: 'Mockobjects-Java-Dev'
> Subject: RE: [MO-java-dev] Javadoc is now online...
> 
> Vincent - very interesting - its both good and bad:
> 
> 1. I have never seen this libary and new nothing about it so it was a
good
> example to give to me

I picked this project because I know it's Craig who wrote it and I know
Craig always produce very nice javadoc.

> 2. The first page was very good - the packages descriptions were
excellent
> -
> the paragraph at the bottom of the page is duplicate of the top though
(so
> REFACTOR)

He he... This is a *feature* of javadoc and it does this automatically
with no duplication whatsoever in the code... ;-)

> 3. I clicked on the first package - the first paragraph is yet again
> another
> copy of the aforementioned one... boy I hope the goal of the project
> doesn't
> change

same here

> 4. The interface descriptions are ok, but you know what? If they just
had
> better names in the first place I wouldn't need the text? Hmmmm
Converter
> -
> I wonder what that does???? The text tells me so much... in fact the
first
> few words give it away "Gneral purpose data type converter... " - gosh
if
> they had called it DataTypeConverter I would really know what it
was...???
> DynaBean and DynaClass are more obscure maybe the docs help (but hey
we've
> started writing docs now so we better keep going... Joke :-) I would
still
> try and think of a better name though

Sure. But it's quite hard to pick good name immediately... and once the
API has been released it's almost impossible...

> 5. Class summaries - I got bored reading those - the names pretty much
did
> it for me
> 6. ConversionExpection - WOW this comment really really made it very
clear
> to me... ;-)
> 7. The Overview - ok now we're talking - leave out 3-6 and get to this
> baby,
> thats more like it.. but you know what the examples make me start to
feel
> nervous... Are they still up to date? If we refactor a method name
would
> the
> docs still be up to date???? I had a quick look and it looks like they
are
> but really a hyperlink (or an inline inclusion of a real test method
would
> be so much more believable) would be better.

Sure. But examples in the doc is what is really most useful. So you need
to make the effort of maintaining. Now, some xdoclet stuff might make it
possible to include source examples in the javadoc automatically. I've
never done it though and I don't know if it is easy to do.

> 
> 8. Although the section after "RowSetDynaClass (Disconnected ResultSet
as
> DynaBeans)" has a non function full paragraph hyperlink
> 9. The sections after this they were obviously running out of steam
and
> the
> formatting gets much worse and the content begins to border on the
> obvious...
> 
> Conclusion -
> 
> Package descriptions seem like a great idea along with a 1 or 2
paragraph
> description (but don't replicate it everywhere). The Introduction with
> example snippets are great - link the real examples (and don't pretend
to
> have the full example in the text). Keep it tight and don't get too
> carried
> away as you run out of steam near the end.
> 
> So yes Vincent - lets pick "cheap" documentation, and get the high
value
> stuff
> 
> Tim
> 
> p.s. Really interestingly, one of the Thoughtworks teams finally took
a
> long
> standing idea and generated docs for a class where they parsed the
test
> names for a class and outputed:
> 
> ClassX is an object that:
> - Handles Zero Items Added
> - Handles N Items With a Null
> - Throw An Exception With An Empty List
> - Allows Mixed Object Addition
> etc.
> 
> Guess what - its all based on writing tests with good names and with a
bit
> of creativity you get pretty good docs and are encouraged to write
good
> test
> names... now thats Interesting dont you thing?

That's a very interesting idea. I'm still a bit skeptical that you'll
ever get good docs out of this though, but then I only want to be
convinced :-)

Thanks
-Vincent

> 
> 
> > -----Original Message-----
> > From: moc...@li...
> > [mailto:moc...@li...]On Behalf
Of
> > Vincent Massol
> > Sent: 04 June 2003 07:53
> > To: 'Tim Mackinnon'; moc...@li...
> > Cc: 'Mockobjects-Java-Dev'
> > Subject: RE: [MO-java-dev] Javadoc is now online...
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Tim Mackinnon [mailto:tim...@po...]
> > > Sent: 04 June 2003 01:41
> > > To: Vincent Massol; moc...@li...
> > > Cc: 'Mockobjects-Java-Dev'
> > > Subject: RE: [MO-java-dev] Javadoc is now online...
> > >
> > > oooh catty.... I can feel the scratches ;-)
> >
> > ;-)
> >
> > >
> > > Yes - I personally think that docs are a crutch for writing bad
code.
> >
> > I won't disagree with that. Writing good doc is for sure as hard as
> > writing good code :-)
> >
> > > I've
> > > tried both and run the experiments and found that if I just wrote
> > better
> > > code, had better method names, better variable names and better
> > examples
> > > and
> > > tests - then the documents needed were very rudimentary. Yes its
hard
> > -
> > > but
> > > it pays off (the result being better code ).
> >
> > Sure but don't say the MockObjects framework is well documented! :-)
> >
> > >
> > > I would prefer people spend effort on a Q&A or a short article
than
> > write
> > > java doc - maybe its a smalltalk thing - once I've got past the
> > > introduction
> > > and seen an example I'm quite happy to browse working code that I
know
> > is
> > > up
> > > to date.
> >
> > You may be missing the overview.html and package.html part of
javadoc
> > which is probably the most fundamental one.
> >
> > >
> > > We seem to disagree on this Vincent - but for all of your feedback
on
> > > requests for documentation I have tried to diligently go back to
the
> > code
> > > and fix what was a problem there in the first place.
> >
> > Sure and I thank you for that! :-)
> >
> > Several things:
> > - first, I personally don't care about the javadoc as I am a
> > "power-user" of MockObjects and I have the code ready on my machine,
> > etc.
> > - Someone asked for it and I have uploaded it for that person. This
is
> > quite a logical request seen that there is almost no doc on
MockObjects
> > or Dyna Mocks and people are used to getting some information from
the
> > javadoc.
> > - Javadoc can be very good. Have a look at the one for BeanUtils for
> > example: http://jakarta.apache.org/commons/beanutils/api/index.html
> > - I agree that the following is useless:
> >
> > /**
> >  * @return the name
> >  */
> > public String getName()
> > {
> > [...]
> >
> > and I would probably agree that there is no need to document this
> > method.
> >
> > Some thoughts:
> >
> > 1/ I think you consider javadoc as a way to document what the logic
of a
> > method does whereas I consider javadoc as a way to explain how a
given
> > method fit in its environment, i.e. what's the purpose of the method
is
> > and how it relates to the other concepts of the
> > application/frwk/whatever.
> >
> > 2/ Public API (not public methods) cannot be changed at will. A
change
> > to a public API breaks all its users. Thus, once you have decided on
a
> > name you cannot change it easily and you need to go through a long
> > process. For example, the getName() above may not be explicit enough
and
> > should really be called getCustomerName() but I can't change it. So
a
> > comment saying that we are talking about a customer name might be
> > helpful.
> >
> > 3/ For me the value of some piece of code is much more than the few
> > lines themselves. It is:
> > - has it been tested (i.e. suite of tests)
> > - does it follow some well-defined coding conventions, i.e is it
easy to
> > read
> > - is it enough documented so that users/extender can understand it
(can
> > be javadoc, unit tests, etc) and is the documentation readily
accesible
> >
> > 4/ What would be nice is a doclet that takes the test code and put
it in
> > javadoc format, next to the behavior tested. Most people will not go
to
> > the source to get the doc so we need a way to simply publish the
unit
> > tests on the doc web site.
> >
> > >
> > > But maybe we do need some documentation that says:
> > >
> > > - How to install it
> > > - Which example to look at first
> > > - What to do next
> > > - How to read the code and use it as the documentation
> >
> > yep. These are all good topics for documentation.
> >
> > Now, I'll shut up because what we need are not words but actions and
I
> > am currently overwhelmed...
> >
> > Thanks Tim!
> > -Vincent
> >
> > >
> > >
> > > Tim
> > >
> > > > -----Original Message-----
> > > > From: moc...@li...
> > > > [mailto:moc...@li...]On
Behalf
> > Of
> > > > Vincent Massol
> > > > Sent: 03 June 2003 08:59
> > > > To: moc...@li...
> > > > Cc: 'Mockobjects-Java-Dev'
> > > > Subject: [MO-java-dev] Javadoc is now online...
> > > >
> > > >
> > > > FWIW, I've put the javadoc online:
> > > >
> > > > http://www.mockobjects.com/wiki/Javadocs
> > > >
> > > > Note: The MockObjects team thinks that javadoc is not needed and
> > that
> > > > good code should generally not need javadoc (i.e. it should be
> > > > sufficiently expressive by itself). Thus you will find that this
> > javadoc
> > > > will not give you any explanation at all! In order to get
> > explanation
> > > > you are invited to read the code :-)
> > > >
> > > > Thanks
> > > > -Vincent
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.net email is sponsored by: eBay
> > > > Get office equipment for less on eBay!
> > > > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> > > > _______________________________________________
> > > > Mockobjects-java-dev mailing list
> > > > Moc...@li...
> > > >
https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> > > >
> > > > ---
> > > > Incoming mail is certified Virus Free.
> > > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > > Version: 6.0.487 / Virus Database: 286 - Release Date:
01/06/2003
> > > >
> > > ---
> > > Outgoing mail is certified Virus Free.
> > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:  Etnus, makers of TotalView, The
best
> > thread debugger on the planet. Designed with thread debugging
features
> > you've never dreamed of, try TotalView 6 free at www.etnus.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.487 / Virus Database: 286 - Release Date: 01/06/2003
> >
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003

RE: [MO-java-dev] Nice Mocks ?

[Francois B. <fb...@us...>]

So, you are saying my ContextListener should do things differently ?  I
don't have much experience with servlets and containers, so maybe my
understanding is not quite right.  Do you have experience doing
implementing ContextListeners ?  I do not and I based my tests on what I
found at
http://www.onjava.com/onjava/2003/01/08/examples/ContextListener.html,
which is a part of the article at
http://www.onjava.com/onjava/2003/01/08/tomcat4.html.

If you have a better way of doing this, I am all open to suggestions !

Thanks,
Fran=E7ois

PS: At the moment, I refactored my tests so that both cases are covered
in a single test.  So, the test is now named
testClosesDbAndRemovesAttributeFromContextOnDestruction().  Phhhew !

On Fri, 6 Jun 2003 01:48:33 +0100, "Tim Mackinnon"
<tim...@po...> said:
> I think there is probably a way to do what you want with the pieces that
> are
> there - or maybe you have some suggestion?
>=20
> The problem is that your test is very contrived - If closing requires
> both a
> removal of teamDb and a close, then its very artificial and rather
> confusing
> to test that behavior in two seperately isolated tests. Just don't do
> that.
>=20
> On the other hand I have seen cases were there is some metchAndReturn
> behavior that can be usefully put in setup so that other tests will get
> default values but in a few tests its strengthened to expectAndReturn to
> assert some specific behavior.
>=20
> Tim
>=20
> > -----Original Message-----
> > From: moc...@li...
> > [mailto:moc...@li...]On Behalf Of
> > Francois Beausoleil
> > Sent: 04 June 2003 13:54
> > To: Tim Mackinnon; moc...@li...
> > Subject: RE: [MO-java-dev] Nice Mocks ?
> >
> >
> > Hello Tim,
> >
> > No, because when I execute the tests for initialization, I do not want
> > the Mock to report problems with the DB close() and removeAttribute()
> > methods.  I want it to report problems with the setAttribute() method a=
nd
> > DB instantiation.
> >
> > Let me reiterate.  The first test asserts that the "teamsdb" attribute
> > will be removed from the context.  The second one asserts that whatever
> > was in the "teamsdb" attribute receives a method call of "close".  Those
> > are two very different tests.  And they assert different things.  I wou=
ld
> > prefer that the first test ignore whatever happens with the actual obje=
ct
> > in the attribute, and that the second test ignore whatever happens with
> > the context.
> >
> > Thanks for your time,
> > Fran=E7ois
> >
> > On Wed, 4 Jun 2003 00:40:32 +0100, "Tim Mackinnon"
> > <tim...@po...> said:
> > > Is this an example of wanting to put in setUp() something like:
> > >
> > >
> > > setUp() {
> > >  servletContext =3D (ServletContext)mockServletContext.proxy();
> > >  ServletContextEvent event =3D new ServletContextEvent(servletContext=
);
> > >
> > >  mockServletContext.match("removeAttribute", C.eq("teamsdb"));
> > >
> > >  // OR
> > >  // mockServletContext.match("removeAttribute", C.ANY_ARGS);
> > > }
> > >
> > > The idea that you can override the match with an expect as in the fir=
st
> > > test
> > > and the second test will just get the match. In this case as that met=
hod
> > > is
> > > void its not matchAndReturn but this gives a nice symmetry for if the=
re
> > > was
> > > a method with a return value.
> > >
> > > I think we don't quite have this but its an easy one to do?
> > >
> > > I have often seen cases where we want default stuff in setup and can
> > > override specific exectations in the relevenat tests.
> > >
> > > Tim
> > >
> > > > -----Original Message-----
> > > > From: moc...@li...
> > > > [mailto:moc...@li...]On Behalf =
Of
> > > > Francois Beausoleil
> > > > Sent: 03 June 2003 19:02
> > > > To: moc...@li...
> > > > Subject: [MO-java-dev] Nice Mocks ?
> > > >
> > > >
> > > > Hello everyone,
> > > >
> > > > I started using 0.09 and I hit a snag.  The class under test is an
> > > > implementation of ContextListener.
> > > >
> > > > I am testing the destruction of the context.  I would like each of =
my
> > > > tests to test the minimum amount of code possible.  So, I
> > would like to
> > > > have a test that confirms that an attribute is removed from
> > the context,
> > > > and a second one to ensure that the DB is closed.  So, here's
> > the code at
> > > > the moment:
> > > >
> > > > public class TestContextListener extends TestCase {
> > > >     private final ContextListener contextListener =3D new
> > > >     ContextListener();
> > > >     private final Mock mockServletContext =3D new
> > > >     Mock(ServletContext.class);
> > > >
> > > >     public void testRemovesTeamDBOnDestruction() {
> > > >         mockServletContext.expect("removeAttribute", C.eq("teamsdb"=
));
> > > >         ServletContext servletContext =3D
> > > >                 (ServletContext)mockServletContext.proxy();
> > > >
> > > >         ServletContextEvent event =3D new
> > > >         ServletContextEvent(servletContext);
> > > >
> > > >         contextListener.contextDestroyed(event);
> > > >
> > > >         mockServletContext.verify();
> > > >     }
> > > >
> > > >     public void testClosesDBOnDestruction() {
> > > >         TeamDB db =3D new TeamDB(); // Need to check close with Mock
> > > >         mockServletContext.expectAndReturn("getAttribute", C.NO_ARG=
S,
> > > >         db);
> > > >
> > > >         ServletContext servletContext =3D
> > > >                 (ServletContext)mockServletContext.proxy();
> > > >
> > > >         ServletContextEvent event =3D new
> > > >         ServletContextEvent(servletContext);
> > > >
> > > >         contextListener.contextDestroyed(event);
> > > >
> > > >         mockServletContext.verify();
> > > >     }
> > > > }
> > > >
> > > > testRemovesTeamDBOnDestruction() passes, since I implemented things
> > > > correctly.  But testClosesDBOnDestruction() does not, as the
> > > > contextListener calls removeAttribute().  But I already know
> > that, since
> > > > the previous test asserts this very thing.  In my case, I
> > would like that
> > > > to not be an assertion failure.
> > > >
> > > > I could always join both tests and call it
> > > > "testRemovesTeamDB_And_ClosesDBOnDestruction()", but I prefer the t=
wo
> > > > simpler methods.
> > > >
> > > > Is there a way to make a Mock accept any method call that has
> > no return
> > > > value and just silently ignore it ?  I believe EasyMock
> > allowed something
> > > > like that and that it was called "Nice Mock".
> > > >
> > > > Thanks !
> > > > Francois
> > > > --
> > > >   Francois Beausoleil
> > > >   Developer of Java Gui Builder
> > > >   http://jgb.sourceforge.net/
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.net email is sponsored by: eBay
> > > > Get office equipment for less on eBay!
> > > > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> > > > _______________________________________________
> > > > Mockobjects-java-dev mailing list
> > > > Moc...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> > > >
> > > > ---
> > > > Incoming mail is certified Virus Free.
> > > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
> > > >
> > > ---
> > > Outgoing mail is certified Virus Free.
> > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by:  Etnus, makers of TotalView, The b=
est
> > > thread debugger on the planet. Designed with thread debugging features
> > > you've never dreamed of, try TotalView 6 free at www.etnus.com.
> > > _______________________________________________
> > > Mockobjects-java-dev mailing list
> > > Moc...@li...
> > > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> > >
> > --
> >   Francois Beausoleil
> >   Developer of Java Gui Builder
> >   http://jgb.sourceforge.net/
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> > thread debugger on the planet. Designed with thread debugging features
> > you've never dreamed of, try TotalView 6 free at www.etnus.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.487 / Virus Database: 286 - Release Date: 01/06/2003
> >
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
>=20
>=20
--
  Francois Beausoleil
  Developer of Java Gui Builder
  http://jgb.sourceforge.net/

RE: [MO-java-dev] Nice Mocks ?

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

I think there is probably a way to do what you want with the pieces that are
there - or maybe you have some suggestion?

The problem is that your test is very contrived - If closing requires both a
removal of teamDb and a close, then its very artificial and rather confusing
to test that behavior in two seperately isolated tests. Just don't do that.

On the other hand I have seen cases were there is some metchAndReturn
behavior that can be usefully put in setup so that other tests will get
default values but in a few tests its strengthened to expectAndReturn to
assert some specific behavior.

Tim

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Francois Beausoleil
> Sent: 04 June 2003 13:54
> To: Tim Mackinnon; moc...@li...
> Subject: RE: [MO-java-dev] Nice Mocks ?
>
>
> Hello Tim,
>
> No, because when I execute the tests for initialization, I do not want
> the Mock to report problems with the DB close() and removeAttribute()
> methods.  I want it to report problems with the setAttribute() method and
> DB instantiation.
>
> Let me reiterate.  The first test asserts that the "teamsdb" attribute
> will be removed from the context.  The second one asserts that whatever
> was in the "teamsdb" attribute receives a method call of "close".  Those
> are two very different tests.  And they assert different things.  I would
> prefer that the first test ignore whatever happens with the actual object
> in the attribute, and that the second test ignore whatever happens with
> the context.
>
> Thanks for your time,
> François
>
> On Wed, 4 Jun 2003 00:40:32 +0100, "Tim Mackinnon"
> <tim...@po...> said:
> > Is this an example of wanting to put in setUp() something like:
> >
> >
> > setUp() {
> >  servletContext = (ServletContext)mockServletContext.proxy();
> >  ServletContextEvent event = new ServletContextEvent(servletContext);
> >
> >  mockServletContext.match("removeAttribute", C.eq("teamsdb"));
> >
> >  // OR
> >  // mockServletContext.match("removeAttribute", C.ANY_ARGS);
> > }
> >
> > The idea that you can override the match with an expect as in the first
> > test
> > and the second test will just get the match. In this case as that method
> > is
> > void its not matchAndReturn but this gives a nice symmetry for if there
> > was
> > a method with a return value.
> >
> > I think we don't quite have this but its an easy one to do?
> >
> > I have often seen cases where we want default stuff in setup and can
> > override specific exectations in the relevenat tests.
> >
> > Tim
> >
> > > -----Original Message-----
> > > From: moc...@li...
> > > [mailto:moc...@li...]On Behalf Of
> > > Francois Beausoleil
> > > Sent: 03 June 2003 19:02
> > > To: moc...@li...
> > > Subject: [MO-java-dev] Nice Mocks ?
> > >
> > >
> > > Hello everyone,
> > >
> > > I started using 0.09 and I hit a snag.  The class under test is an
> > > implementation of ContextListener.
> > >
> > > I am testing the destruction of the context.  I would like each of my
> > > tests to test the minimum amount of code possible.  So, I
> would like to
> > > have a test that confirms that an attribute is removed from
> the context,
> > > and a second one to ensure that the DB is closed.  So, here's
> the code at
> > > the moment:
> > >
> > > public class TestContextListener extends TestCase {
> > >     private final ContextListener contextListener = new
> > >     ContextListener();
> > >     private final Mock mockServletContext = new
> > >     Mock(ServletContext.class);
> > >
> > >     public void testRemovesTeamDBOnDestruction() {
> > >         mockServletContext.expect("removeAttribute", C.eq("teamsdb"));
> > >         ServletContext servletContext =
> > >                 (ServletContext)mockServletContext.proxy();
> > >
> > >         ServletContextEvent event = new
> > >         ServletContextEvent(servletContext);
> > >
> > >         contextListener.contextDestroyed(event);
> > >
> > >         mockServletContext.verify();
> > >     }
> > >
> > >     public void testClosesDBOnDestruction() {
> > >         TeamDB db = new TeamDB(); // Need to check close with Mock
> > >         mockServletContext.expectAndReturn("getAttribute", C.NO_ARGS,
> > >         db);
> > >
> > >         ServletContext servletContext =
> > >                 (ServletContext)mockServletContext.proxy();
> > >
> > >         ServletContextEvent event = new
> > >         ServletContextEvent(servletContext);
> > >
> > >         contextListener.contextDestroyed(event);
> > >
> > >         mockServletContext.verify();
> > >     }
> > > }
> > >
> > > testRemovesTeamDBOnDestruction() passes, since I implemented things
> > > correctly.  But testClosesDBOnDestruction() does not, as the
> > > contextListener calls removeAttribute().  But I already know
> that, since
> > > the previous test asserts this very thing.  In my case, I
> would like that
> > > to not be an assertion failure.
> > >
> > > I could always join both tests and call it
> > > "testRemovesTeamDB_And_ClosesDBOnDestruction()", but I prefer the two
> > > simpler methods.
> > >
> > > Is there a way to make a Mock accept any method call that has
> no return
> > > value and just silently ignore it ?  I believe EasyMock
> allowed something
> > > like that and that it was called "Nice Mock".
> > >
> > > Thanks !
> > > Francois
> > > --
> > >   Francois Beausoleil
> > >   Developer of Java Gui Builder
> > >   http://jgb.sourceforge.net/
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: eBay
> > > Get office equipment for less on eBay!
> > > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> > > _______________________________________________
> > > Mockobjects-java-dev mailing list
> > > Moc...@li...
> > > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> > >
> > > ---
> > > Incoming mail is certified Virus Free.
> > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
> > >
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> > thread debugger on the planet. Designed with thread debugging features
> > you've never dreamed of, try TotalView 6 free at www.etnus.com.
> > _______________________________________________
> > Mockobjects-java-dev mailing list
> > Moc...@li...
> > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> >
> --
>   Francois Beausoleil
>   Developer of Java Gui Builder
>   http://jgb.sourceforge.net/
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.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.487 / Virus Database: 286 - Release Date: 01/06/2003
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003

RE: [MO-java-dev] Javadoc is now online...

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

Vincent - very interesting - its both good and bad:

1. I have never seen this libary and new nothing about it so it was a good
example to give to me
2. The first page was very good - the packages descriptions were excellent -
the paragraph at the bottom of the page is duplicate of the top though (so
REFACTOR)
3. I clicked on the first package - the first paragraph is yet again another
copy of the aforementioned one... boy I hope the goal of the project doesn't
change
4. The interface descriptions are ok, but you know what? If they just had
better names in the first place I wouldn't need the text? Hmmmm Converter -
I wonder what that does???? The text tells me so much... in fact the first
few words give it away "Gneral purpose data type converter... " - gosh if
they had called it DataTypeConverter I would really know what it was...???
DynaBean and DynaClass are more obscure maybe the docs help (but hey we've
started writing docs now so we better keep going... Joke :-) I would still
try and think of a better name though
5. Class summaries - I got bored reading those - the names pretty much did
it for me
6. ConversionExpection - WOW this comment really really made it very clear
to me... ;-)
7. The Overview - ok now we're talking - leave out 3-6 and get to this baby,
thats more like it.. but you know what the examples make me start to feel
nervous... Are they still up to date? If we refactor a method name would the
docs still be up to date???? I had a quick look and it looks like they are
but really a hyperlink (or an inline inclusion of a real test method would
be so much more believable) would be better.

8. Although the section after "RowSetDynaClass (Disconnected ResultSet as
DynaBeans)" has a non function full paragraph hyperlink
9. The sections after this they were obviously running out of steam and the
formatting gets much worse and the content begins to border on the
obvious...

Conclusion -

Package descriptions seem like a great idea along with a 1 or 2 paragraph
description (but don't replicate it everywhere). The Introduction with
example snippets are great - link the real examples (and don't pretend to
have the full example in the text). Keep it tight and don't get too carried
away as you run out of steam near the end.

So yes Vincent - lets pick "cheap" documentation, and get the high value
stuff

Tim

p.s. Really interestingly, one of the Thoughtworks teams finally took a long
standing idea and generated docs for a class where they parsed the test
names for a class and outputed:

ClassX is an object that:
- Handles Zero Items Added
- Handles N Items With a Null
- Throw An Exception With An Empty List
- Allows Mixed Object Addition
etc.

Guess what - its all based on writing tests with good names and with a bit
of creativity you get pretty good docs and are encouraged to write good test
names... now thats Interesting dont you thing?


> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Vincent Massol
> Sent: 04 June 2003 07:53
> To: 'Tim Mackinnon'; moc...@li...
> Cc: 'Mockobjects-Java-Dev'
> Subject: RE: [MO-java-dev] Javadoc is now online...
>
>
>
>
> > -----Original Message-----
> > From: Tim Mackinnon [mailto:tim...@po...]
> > Sent: 04 June 2003 01:41
> > To: Vincent Massol; moc...@li...
> > Cc: 'Mockobjects-Java-Dev'
> > Subject: RE: [MO-java-dev] Javadoc is now online...
> >
> > oooh catty.... I can feel the scratches ;-)
>
> ;-)
>
> >
> > Yes - I personally think that docs are a crutch for writing bad code.
>
> I won't disagree with that. Writing good doc is for sure as hard as
> writing good code :-)
>
> > I've
> > tried both and run the experiments and found that if I just wrote
> better
> > code, had better method names, better variable names and better
> examples
> > and
> > tests - then the documents needed were very rudimentary. Yes its hard
> -
> > but
> > it pays off (the result being better code ).
>
> Sure but don't say the MockObjects framework is well documented! :-)
>
> >
> > I would prefer people spend effort on a Q&A or a short article than
> write
> > java doc - maybe its a smalltalk thing - once I've got past the
> > introduction
> > and seen an example I'm quite happy to browse working code that I know
> is
> > up
> > to date.
>
> You may be missing the overview.html and package.html part of javadoc
> which is probably the most fundamental one.
>
> >
> > We seem to disagree on this Vincent - but for all of your feedback on
> > requests for documentation I have tried to diligently go back to the
> code
> > and fix what was a problem there in the first place.
>
> Sure and I thank you for that! :-)
>
> Several things:
> - first, I personally don't care about the javadoc as I am a
> "power-user" of MockObjects and I have the code ready on my machine,
> etc.
> - Someone asked for it and I have uploaded it for that person. This is
> quite a logical request seen that there is almost no doc on MockObjects
> or Dyna Mocks and people are used to getting some information from the
> javadoc.
> - Javadoc can be very good. Have a look at the one for BeanUtils for
> example: http://jakarta.apache.org/commons/beanutils/api/index.html
> - I agree that the following is useless:
>
> /**
>  * @return the name
>  */
> public String getName()
> {
> [...]
>
> and I would probably agree that there is no need to document this
> method.
>
> Some thoughts:
>
> 1/ I think you consider javadoc as a way to document what the logic of a
> method does whereas I consider javadoc as a way to explain how a given
> method fit in its environment, i.e. what's the purpose of the method is
> and how it relates to the other concepts of the
> application/frwk/whatever.
>
> 2/ Public API (not public methods) cannot be changed at will. A change
> to a public API breaks all its users. Thus, once you have decided on a
> name you cannot change it easily and you need to go through a long
> process. For example, the getName() above may not be explicit enough and
> should really be called getCustomerName() but I can't change it. So a
> comment saying that we are talking about a customer name might be
> helpful.
>
> 3/ For me the value of some piece of code is much more than the few
> lines themselves. It is:
> - has it been tested (i.e. suite of tests)
> - does it follow some well-defined coding conventions, i.e is it easy to
> read
> - is it enough documented so that users/extender can understand it (can
> be javadoc, unit tests, etc) and is the documentation readily accesible
>
> 4/ What would be nice is a doclet that takes the test code and put it in
> javadoc format, next to the behavior tested. Most people will not go to
> the source to get the doc so we need a way to simply publish the unit
> tests on the doc web site.
>
> >
> > But maybe we do need some documentation that says:
> >
> > - How to install it
> > - Which example to look at first
> > - What to do next
> > - How to read the code and use it as the documentation
>
> yep. These are all good topics for documentation.
>
> Now, I'll shut up because what we need are not words but actions and I
> am currently overwhelmed...
>
> Thanks Tim!
> -Vincent
>
> >
> >
> > Tim
> >
> > > -----Original Message-----
> > > From: moc...@li...
> > > [mailto:moc...@li...]On Behalf
> Of
> > > Vincent Massol
> > > Sent: 03 June 2003 08:59
> > > To: moc...@li...
> > > Cc: 'Mockobjects-Java-Dev'
> > > Subject: [MO-java-dev] Javadoc is now online...
> > >
> > >
> > > FWIW, I've put the javadoc online:
> > >
> > > http://www.mockobjects.com/wiki/Javadocs
> > >
> > > Note: The MockObjects team thinks that javadoc is not needed and
> that
> > > good code should generally not need javadoc (i.e. it should be
> > > sufficiently expressive by itself). Thus you will find that this
> javadoc
> > > will not give you any explanation at all! In order to get
> explanation
> > > you are invited to read the code :-)
> > >
> > > Thanks
> > > -Vincent
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: eBay
> > > Get office equipment for less on eBay!
> > > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> > > _______________________________________________
> > > Mockobjects-java-dev mailing list
> > > Moc...@li...
> > > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> > >
> > > ---
> > > Incoming mail is certified Virus Free.
> > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
> > >
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.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.487 / Virus Database: 286 - Release Date: 01/06/2003
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003

Re: [MO-java-dev] Javadoc is now online...

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

I think Vincent has some valid points. What's missing is not the dumb 
"conformant" javadoc, but the more explanatory background writing, and 
the package and class docs may be as a good a place to put them as 
anywhere. Of course, we're all short of time. The purpose of this kind 
of writing is different from the sort of doc that we love to hate.

S.

RE: [MO-java-dev] Suggested mod to ExpectationValue

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

Dan - something sounds strange there. In the legacy mock stuff the
ExpectationValue is used to check input parameters. There is a separate
object for results called ReturnObjectList. You probably shouldn't confuse
the two. Look at the code that MockMaker generates as guide.

However I wonder if you might be better of looking that the dynamic mock
stuff - we are mostly using that now and it has the concept of:

  anObject.expectAndReturn("getTitle", "Charles Dickens", "Great
Expectations");

E.g. you can set an expectation and set the return value in one step, which
I think is what you are hinting at.

Tim

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Dan Cramer
> Sent: 01 June 2003 18:38
> To: Mockobjects-Dev
> Subject: [MO-java-dev] Suggested mod to ExpectationValue
>
>
> Hello. I'm new to using mock objects, so, maybe I'm using something
> wrong, but I'd like to suggest adding the following to
> com.mockobjects.ExpectationValue:
>
> 	/**
> 	 * Provide access to the expected value for this expectation so
> that
> 	 * mock objects can return that value to clients.
> 	 */
> 	public Object getExpected()
> 	{
> 		return myExpectedValue;
> 	}
>
> This would allow a mock to use the expected value to implement its
> interface. For example, I have an object that's supposed to have some
> properties set on it at one point and then retrieved later in the same
> workflow. In order to use expectation value, the way it's currently
> written, I find myself having two variables: the expectation and a value
> (same thing that's stored in the expectation.
>
> Comments/Suggestions? Am I doing something wrong?
>
> Sincerely,
> Dan Cramer
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003

RE: [MO-java-dev] Nice Mocks ?

[Francois B. <fb...@us...>]

Hello Tim,

No, because when I execute the tests for initialization, I do not want
the Mock to report problems with the DB close() and removeAttribute()
methods.  I want it to report problems with the setAttribute() method and
DB instantiation.

Let me reiterate.  The first test asserts that the "teamsdb" attribute
will be removed from the context.  The second one asserts that whatever
was in the "teamsdb" attribute receives a method call of "close".  Those
are two very different tests.  And they assert different things.  I would
prefer that the first test ignore whatever happens with the actual object
in the attribute, and that the second test ignore whatever happens with
the context.

Thanks for your time,
Fran=E7ois

On Wed, 4 Jun 2003 00:40:32 +0100, "Tim Mackinnon"
<tim...@po...> said:
> Is this an example of wanting to put in setUp() something like:
>=20
>=20
> setUp() {
>  servletContext =3D (ServletContext)mockServletContext.proxy();
>  ServletContextEvent event =3D new ServletContextEvent(servletContext);
>=20
>  mockServletContext.match("removeAttribute", C.eq("teamsdb"));
>=20
>  // OR
>  // mockServletContext.match("removeAttribute", C.ANY_ARGS);
> }
>=20
> The idea that you can override the match with an expect as in the first
> test
> and the second test will just get the match. In this case as that method
> is
> void its not matchAndReturn but this gives a nice symmetry for if there
> was
> a method with a return value.
>=20
> I think we don't quite have this but its an easy one to do?
>=20
> I have often seen cases where we want default stuff in setup and can
> override specific exectations in the relevenat tests.
>=20
> Tim
>=20
> > -----Original Message-----
> > From: moc...@li...
> > [mailto:moc...@li...]On Behalf Of
> > Francois Beausoleil
> > Sent: 03 June 2003 19:02
> > To: moc...@li...
> > Subject: [MO-java-dev] Nice Mocks ?
> >
> >
> > Hello everyone,
> >
> > I started using 0.09 and I hit a snag.  The class under test is an
> > implementation of ContextListener.
> >
> > I am testing the destruction of the context.  I would like each of my
> > tests to test the minimum amount of code possible.  So, I would like to
> > have a test that confirms that an attribute is removed from the context,
> > and a second one to ensure that the DB is closed.  So, here's the code =
at
> > the moment:
> >
> > public class TestContextListener extends TestCase {
> >     private final ContextListener contextListener =3D new
> >     ContextListener();
> >     private final Mock mockServletContext =3D new
> >     Mock(ServletContext.class);
> >
> >     public void testRemovesTeamDBOnDestruction() {
> >         mockServletContext.expect("removeAttribute", C.eq("teamsdb"));
> >         ServletContext servletContext =3D
> >                 (ServletContext)mockServletContext.proxy();
> >
> >         ServletContextEvent event =3D new
> >         ServletContextEvent(servletContext);
> >
> >         contextListener.contextDestroyed(event);
> >
> >         mockServletContext.verify();
> >     }
> >
> >     public void testClosesDBOnDestruction() {
> >         TeamDB db =3D new TeamDB(); // Need to check close with Mock
> >         mockServletContext.expectAndReturn("getAttribute", C.NO_ARGS,
> >         db);
> >
> >         ServletContext servletContext =3D
> >                 (ServletContext)mockServletContext.proxy();
> >
> >         ServletContextEvent event =3D new
> >         ServletContextEvent(servletContext);
> >
> >         contextListener.contextDestroyed(event);
> >
> >         mockServletContext.verify();
> >     }
> > }
> >
> > testRemovesTeamDBOnDestruction() passes, since I implemented things
> > correctly.  But testClosesDBOnDestruction() does not, as the
> > contextListener calls removeAttribute().  But I already know that, since
> > the previous test asserts this very thing.  In my case, I would like th=
at
> > to not be an assertion failure.
> >
> > I could always join both tests and call it
> > "testRemovesTeamDB_And_ClosesDBOnDestruction()", but I prefer the two
> > simpler methods.
> >
> > Is there a way to make a Mock accept any method call that has no return
> > value and just silently ignore it ?  I believe EasyMock allowed somethi=
ng
> > like that and that it was called "Nice Mock".
> >
> > Thanks !
> > Francois
> > --
> >   Francois Beausoleil
> >   Developer of Java Gui Builder
> >   http://jgb.sourceforge.net/
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: eBay
> > Get office equipment for less on eBay!
> > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> > _______________________________________________
> > Mockobjects-java-dev mailing list
> > Moc...@li...
> > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> >
> > ---
> > Incoming mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
> >
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>=20
--
  Francois Beausoleil
  Developer of Java Gui Builder
  http://jgb.sourceforge.net/

RE: [MO-java-dev] Quick Wiki question

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

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...] On Behalf Of
Nat
> Pryce
> Sent: 04 June 2003 10:15
> To: Moc...@Li...
> Subject: [MO-java-dev] Quick Wiki question
> 
> The Mock Objects Wiki allows links with spaces in the name, using the
> format
> ["A Link With Spaces In The Name"] but nobody uses them.  Are they
avoided
> by convention? Or are they deemed ok?

I'm quite sure I have used them on the mockobjects wiki. My view is that
they are ok.

-Vincent

> 
> Cheers,
>             Nat.
> _______________________
> Dr. Nathaniel Pryce
> B13media Ltd.
> http://www.b13media.com
> +44 (0)7712 526 661
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The
best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev

Re: [MO-java-dev] Quick Wiki question

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

Whatever works best, but if you use CamelCase it's easier to find and more =
likely to have someone else fill it in as a side effect.

S.

> The Mock Objects Wiki allows links with spaces in the name, using the for=
mat
> ["A Link With Spaces In The Name"] but nobody uses them.  Are they avoided
> by convention? Or are they deemed ok?

[MO-java-dev] Quick Wiki question

[Nat P. <nat...@b1...>]

The Mock Objects Wiki allows links with spaces in the name, using the format
["A Link With Spaces In The Name"] but nobody uses them.  Are they avoided
by convention? Or are they deemed ok?

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

Re: [MO-java-users] RE: [MO-java-dev] Javadoc is now online...

[Nat P. <nat...@b1...>]

Perhaps, for starters, it would be a good idea to take interesting threads
from the mailing list and copy them on the Wiki, in edited form, to be
preserved for posterity.  This idea is already used The Ruby wiki.  These
threads could then be refactored into other kinds of documentation.

For example, the recent a.equals(b) vs b.equals(a) thread would be a good
candidate to move to the wiki.

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


----- Original Message -----
From: "Tim Mackinnon" <tim...@po...>
To: "Vincent Massol" <vm...@pi...>;
<moc...@li...>
Cc: "'Mockobjects-Java-Dev'" <moc...@li...>
Sent: Wednesday, June 04, 2003 12:40 AM
Subject: [MO-java-users] RE: [MO-java-dev] Javadoc is now online...


> oooh catty.... I can feel the scratches ;-)
>
> Yes - I personally think that docs are a crutch for writing bad code. I've
> tried both and run the experiments and found that if I just wrote better
> code, had better method names, better variable names and better examples
and
> tests - then the documents needed were very rudimentary. Yes its hard -
but
> it pays off (the result being better code ).
>
> I would prefer people spend effort on a Q&A or a short article than write
> java doc - maybe its a smalltalk thing - once I've got past the
introduction
> and seen an example I'm quite happy to browse working code that I know is
up
> to date.
>
> We seem to disagree on this Vincent - but for all of your feedback on
> requests for documentation I have tried to diligently go back to the code
> and fix what was a problem there in the first place.
>
> But maybe we do need some documentation that says:
>
> - How to install it
> - Which example to look at first
> - What to do next
> - How to read the code and use it as the documentation
>
>
> Tim
>
> > -----Original Message-----
> > From: moc...@li...
> > [mailto:moc...@li...]On Behalf Of
> > Vincent Massol
> > Sent: 03 June 2003 08:59
> > To: moc...@li...
> > Cc: 'Mockobjects-Java-Dev'
> > Subject: [MO-java-dev] Javadoc is now online...
> >
> >
> > FWIW, I've put the javadoc online:
> >
> > http://www.mockobjects.com/wiki/Javadocs
> >
> > Note: The MockObjects team thinks that javadoc is not needed and that
> > good code should generally not need javadoc (i.e. it should be
> > sufficiently expressive by itself). Thus you will find that this javadoc
> > will not give you any explanation at all! In order to get explanation
> > you are invited to read the code :-)
> >
> > Thanks
> > -Vincent
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: eBay
> > Get office equipment for less on eBay!
> > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> > _______________________________________________
> > Mockobjects-java-dev mailing list
> > Moc...@li...
> > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> >
> > ---
> > Incoming mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
> >
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users

RE: [MO-java-dev] Javadoc is now online...

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

> -----Original Message-----
> From: Tim Mackinnon [mailto:tim...@po...]
> Sent: 04 June 2003 01:41
> To: Vincent Massol; moc...@li...
> Cc: 'Mockobjects-Java-Dev'
> Subject: RE: [MO-java-dev] Javadoc is now online...
> 
> oooh catty.... I can feel the scratches ;-)

;-)

> 
> Yes - I personally think that docs are a crutch for writing bad code. 

I won't disagree with that. Writing good doc is for sure as hard as
writing good code :-)

> I've
> tried both and run the experiments and found that if I just wrote
better
> code, had better method names, better variable names and better
examples
> and
> tests - then the documents needed were very rudimentary. Yes its hard
-
> but
> it pays off (the result being better code ).

Sure but don't say the MockObjects framework is well documented! :-)

> 
> I would prefer people spend effort on a Q&A or a short article than
write
> java doc - maybe its a smalltalk thing - once I've got past the
> introduction
> and seen an example I'm quite happy to browse working code that I know
is
> up
> to date.

You may be missing the overview.html and package.html part of javadoc
which is probably the most fundamental one.

> 
> We seem to disagree on this Vincent - but for all of your feedback on
> requests for documentation I have tried to diligently go back to the
code
> and fix what was a problem there in the first place.

Sure and I thank you for that! :-)

Several things:
- first, I personally don't care about the javadoc as I am a
"power-user" of MockObjects and I have the code ready on my machine,
etc. 
- Someone asked for it and I have uploaded it for that person. This is
quite a logical request seen that there is almost no doc on MockObjects
or Dyna Mocks and people are used to getting some information from the
javadoc. 
- Javadoc can be very good. Have a look at the one for BeanUtils for
example: http://jakarta.apache.org/commons/beanutils/api/index.html
- I agree that the following is useless:

/**
 * @return the name
 */
public String getName()
{
[...]

and I would probably agree that there is no need to document this
method. 

Some thoughts:
 
1/ I think you consider javadoc as a way to document what the logic of a
method does whereas I consider javadoc as a way to explain how a given
method fit in its environment, i.e. what's the purpose of the method is
and how it relates to the other concepts of the
application/frwk/whatever.

2/ Public API (not public methods) cannot be changed at will. A change
to a public API breaks all its users. Thus, once you have decided on a
name you cannot change it easily and you need to go through a long
process. For example, the getName() above may not be explicit enough and
should really be called getCustomerName() but I can't change it. So a
comment saying that we are talking about a customer name might be
helpful.

3/ For me the value of some piece of code is much more than the few
lines themselves. It is:
- has it been tested (i.e. suite of tests)
- does it follow some well-defined coding conventions, i.e is it easy to
read
- is it enough documented so that users/extender can understand it (can
be javadoc, unit tests, etc) and is the documentation readily accesible

4/ What would be nice is a doclet that takes the test code and put it in
javadoc format, next to the behavior tested. Most people will not go to
the source to get the doc so we need a way to simply publish the unit
tests on the doc web site.

> 
> But maybe we do need some documentation that says:
> 
> - How to install it
> - Which example to look at first
> - What to do next
> - How to read the code and use it as the documentation

yep. These are all good topics for documentation.

Now, I'll shut up because what we need are not words but actions and I
am currently overwhelmed...

Thanks Tim!
-Vincent

> 
> 
> Tim
> 
> > -----Original Message-----
> > From: moc...@li...
> > [mailto:moc...@li...]On Behalf
Of
> > Vincent Massol
> > Sent: 03 June 2003 08:59
> > To: moc...@li...
> > Cc: 'Mockobjects-Java-Dev'
> > Subject: [MO-java-dev] Javadoc is now online...
> >
> >
> > FWIW, I've put the javadoc online:
> >
> > http://www.mockobjects.com/wiki/Javadocs
> >
> > Note: The MockObjects team thinks that javadoc is not needed and
that
> > good code should generally not need javadoc (i.e. it should be
> > sufficiently expressive by itself). Thus you will find that this
javadoc
> > will not give you any explanation at all! In order to get
explanation
> > you are invited to read the code :-)
> >
> > Thanks
> > -Vincent
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: eBay
> > Get office equipment for less on eBay!
> > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> > _______________________________________________
> > Mockobjects-java-dev mailing list
> > Moc...@li...
> > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> >
> > ---
> > Incoming mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
> >
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003

RE: [MO-java-dev] RFE - buildable src archives

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

Paul - that would be fab. We really are after a nice and simple build with
minimum maintenance requirements. So please jump in and reccomend stuff even
if its pretty radical.

Tim

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Paul Nasrat
> Sent: 03 June 2003 15:24
> To: moc...@li...
> Subject: [MO-java-dev] RFE - buildable src archives
>
>
> Hi all,
>
> As part of my work on jpackage I wanted to package up mockobjects.  I
> was disapointed to find that the src archives are not really up to
> scratch :(
>
> The zip/tar.gz does not include the ant scripts, etc which are in CVS.
> In addition mockobjects-src-0.09.tar.gz includes CVS dirs so isn't an
> exported build.
>
> If people want I can have a look at this as I'd like it so I can just
> download a zip/tar.gz and then get it to build and package as RPM for
> jpackage. I've slurped the src and will poke at the ant build script.
>
> Views/opinions/flames welcome
>
> Paul
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003

RE: [MO-java-dev] Nice Mocks ?

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

Is this an example of wanting to put in setUp() something like:


setUp() {
 servletContext = (ServletContext)mockServletContext.proxy();
 ServletContextEvent event = new ServletContextEvent(servletContext);

 mockServletContext.match("removeAttribute", C.eq("teamsdb"));

 // OR
 // mockServletContext.match("removeAttribute", C.ANY_ARGS);
}

The idea that you can override the match with an expect as in the first test
and the second test will just get the match. In this case as that method is
void its not matchAndReturn but this gives a nice symmetry for if there was
a method with a return value.

I think we don't quite have this but its an easy one to do?

I have often seen cases where we want default stuff in setup and can
override specific exectations in the relevenat tests.

Tim

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Francois Beausoleil
> Sent: 03 June 2003 19:02
> To: moc...@li...
> Subject: [MO-java-dev] Nice Mocks ?
>
>
> Hello everyone,
>
> I started using 0.09 and I hit a snag.  The class under test is an
> implementation of ContextListener.
>
> I am testing the destruction of the context.  I would like each of my
> tests to test the minimum amount of code possible.  So, I would like to
> have a test that confirms that an attribute is removed from the context,
> and a second one to ensure that the DB is closed.  So, here's the code at
> the moment:
>
> public class TestContextListener extends TestCase {
>     private final ContextListener contextListener = new
>     ContextListener();
>     private final Mock mockServletContext = new
>     Mock(ServletContext.class);
>
>     public void testRemovesTeamDBOnDestruction() {
>         mockServletContext.expect("removeAttribute", C.eq("teamsdb"));
>         ServletContext servletContext =
>                 (ServletContext)mockServletContext.proxy();
>
>         ServletContextEvent event = new
>         ServletContextEvent(servletContext);
>
>         contextListener.contextDestroyed(event);
>
>         mockServletContext.verify();
>     }
>
>     public void testClosesDBOnDestruction() {
>         TeamDB db = new TeamDB(); // Need to check close with Mock
>         mockServletContext.expectAndReturn("getAttribute", C.NO_ARGS,
>         db);
>
>         ServletContext servletContext =
>                 (ServletContext)mockServletContext.proxy();
>
>         ServletContextEvent event = new
>         ServletContextEvent(servletContext);
>
>         contextListener.contextDestroyed(event);
>
>         mockServletContext.verify();
>     }
> }
>
> testRemovesTeamDBOnDestruction() passes, since I implemented things
> correctly.  But testClosesDBOnDestruction() does not, as the
> contextListener calls removeAttribute().  But I already know that, since
> the previous test asserts this very thing.  In my case, I would like that
> to not be an assertion failure.
>
> I could always join both tests and call it
> "testRemovesTeamDB_And_ClosesDBOnDestruction()", but I prefer the two
> simpler methods.
>
> Is there a way to make a Mock accept any method call that has no return
> value and just silently ignore it ?  I believe EasyMock allowed something
> like that and that it was called "Nice Mock".
>
> Thanks !
> Francois
> --
>   Francois Beausoleil
>   Developer of Java Gui Builder
>   http://jgb.sourceforge.net/
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003

RE: [MO-java-dev] Javadoc is now online...

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

oooh catty.... I can feel the scratches ;-)

Yes - I personally think that docs are a crutch for writing bad code. I've
tried both and run the experiments and found that if I just wrote better
code, had better method names, better variable names and better examples and
tests - then the documents needed were very rudimentary. Yes its hard - but
it pays off (the result being better code ).

I would prefer people spend effort on a Q&A or a short article than write
java doc - maybe its a smalltalk thing - once I've got past the introduction
and seen an example I'm quite happy to browse working code that I know is up
to date.

We seem to disagree on this Vincent - but for all of your feedback on
requests for documentation I have tried to diligently go back to the code
and fix what was a problem there in the first place.

But maybe we do need some documentation that says:

- How to install it
- Which example to look at first
- What to do next
- How to read the code and use it as the documentation


Tim

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Vincent Massol
> Sent: 03 June 2003 08:59
> To: moc...@li...
> Cc: 'Mockobjects-Java-Dev'
> Subject: [MO-java-dev] Javadoc is now online...
>
>
> FWIW, I've put the javadoc online:
>
> http://www.mockobjects.com/wiki/Javadocs
>
> Note: The MockObjects team thinks that javadoc is not needed and that
> good code should generally not need javadoc (i.e. it should be
> sufficiently expressive by itself). Thus you will find that this javadoc
> will not give you any explanation at all! In order to get explanation
> you are invited to read the code :-)
>
> Thanks
> -Vincent
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003

Re: [MO-java-dev] RFE - buildable src archives

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

Be my guest. I started to work on this and got as far as renaming the
jar files. I suspect you'll do a much better job than me ;) and probably
in a lot less time.

I case they're of any use here's the spec files I had.

On Tue, 2003-06-03 at 15:23, Paul Nasrat wrote:
> Hi all,
> 
> As part of my work on jpackage I wanted to package up mockobjects.  I
> was disapointed to find that the src archives are not really up to
> scratch :(
> 
> The zip/tar.gz does not include the ant scripts, etc which are in CVS.
> In addition mockobjects-src-0.09.tar.gz includes CVS dirs so isn't an
> exported build.
> 
> If people want I can have a look at this as I'd like it so I can just
> download a zip/tar.gz and then get it to build and package as RPM for
> jpackage. I've slurped the src and will poke at the ant build script.
> 
> Views/opinions/flames welcome
> 
> Paul
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
-- 

jeff martin
information technologist
mkodo limited

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

www.mkodo.com

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

[MO-java-dev] Nice Mocks ?

[Francois B. <fb...@us...>]

Hello everyone,

I started using 0.09 and I hit a snag.  The class under test is an
implementation of ContextListener.

I am testing the destruction of the context.  I would like each of my
tests to test the minimum amount of code possible.  So, I would like to
have a test that confirms that an attribute is removed from the context,
and a second one to ensure that the DB is closed.  So, here's the code at
the moment:

public class TestContextListener extends TestCase {
    private final ContextListener contextListener = new
    ContextListener();
    private final Mock mockServletContext = new
    Mock(ServletContext.class);

    public void testRemovesTeamDBOnDestruction() {
        mockServletContext.expect("removeAttribute", C.eq("teamsdb"));
        ServletContext servletContext =
                (ServletContext)mockServletContext.proxy();

        ServletContextEvent event = new
        ServletContextEvent(servletContext);

        contextListener.contextDestroyed(event);

        mockServletContext.verify();
    }

    public void testClosesDBOnDestruction() {
        TeamDB db = new TeamDB(); // Need to check close with Mock
        mockServletContext.expectAndReturn("getAttribute", C.NO_ARGS,
        db);

        ServletContext servletContext =
                (ServletContext)mockServletContext.proxy();

        ServletContextEvent event = new
        ServletContextEvent(servletContext);

        contextListener.contextDestroyed(event);

        mockServletContext.verify();
    }
}

testRemovesTeamDBOnDestruction() passes, since I implemented things
correctly.  But testClosesDBOnDestruction() does not, as the
contextListener calls removeAttribute().  But I already know that, since
the previous test asserts this very thing.  In my case, I would like that
to not be an assertion failure.

I could always join both tests and call it
"testRemovesTeamDB_And_ClosesDBOnDestruction()", but I prefer the two
simpler methods.

Is there a way to make a Mock accept any method call that has no return
value and just silently ignore it ?  I believe EasyMock allowed something
like that and that it was called "Nice Mock".

Thanks !
Francois
--
  Francois Beausoleil
  Developer of Java Gui Builder
  http://jgb.sourceforge.net/

RE: [MO-java-dev] RFE - buildable src archives

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

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...] On Behalf Of
> Paul Nasrat
> Sent: 03 June 2003 16:24
> To: moc...@li...
> Subject: [MO-java-dev] RFE - buildable src archives
> 
> Hi all,
> 
> As part of my work on jpackage I wanted to package up mockobjects.  I
> was disapointed to find that the src archives are not really up to
> scratch :(
> 
> The zip/tar.gz does not include the ant scripts, etc which are in CVS.
> In addition mockobjects-src-0.09.tar.gz includes CVS dirs so isn't an
> exported build.
> 
> If people want I can have a look at this as I'd like it so I can just
> download a zip/tar.gz and then get it to build and package as RPM for
> jpackage. I've slurped the src and will poke at the ant build script.
> 
> Views/opinions/flames welcome

big +1 from me :-)

Thanks
-Vincent

> 
> Paul
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev

[MO-java-dev] RFE - buildable src archives

[Paul N. <pa...@tr...>]

Hi all,

As part of my work on jpackage I wanted to package up mockobjects.  I
was disapointed to find that the src archives are not really up to
scratch :(

The zip/tar.gz does not include the ant scripts, etc which are in CVS.
In addition mockobjects-src-0.09.tar.gz includes CVS dirs so isn't an
exported build.

If people want I can have a look at this as I'd like it so I can just
download a zip/tar.gz and then get it to build and package as RPM for
jpackage. I've slurped the src and will poke at the ant build script.

Views/opinions/flames welcome

Paul

[MO-java-dev] Javadoc is now online...

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

FWIW, I've put the javadoc online:

http://www.mockobjects.com/wiki/Javadocs

Note: The MockObjects team thinks that javadoc is not needed and that
good code should generally not need javadoc (i.e. it should be
sufficiently expressive by itself). Thus you will find that this javadoc
will not give you any explanation at all! In order to get explanation
you are invited to read the code :-)

Thanks
-Vincent

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

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

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

Modified Files:
	build.xml 
Log Message:
Postfixed version with "dev" to differentiate it from the future release

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

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

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

> -----Original Message-----
> From: Joe Walnes [mailto:jo...@tr...]
> Sent: 03 June 2003 09:15
> To: Vincent Massol
> Cc: 'Mockobjects-Java-Dev'
> Subject: Re: FW: [MockObjects] Update of "Faq"
> 
> Vincent Massol wrote:
> 
> >Now that the mockobjects web site is a pure wiki, how do we upload
> >things like the javadoc?
> >
> >(Joe, is there an area that you could make available for that on the
> >server hosting the wiki?)
> >
> >Thanks
> >-Vincent
> >
> >
> Good point.
> 
> It's possible to upload individual files to the wiki (inline images,
> downloadables and even through a funky online diagram editor). See
> http://www.mockobjects.com/wiki/HelpOnActions/AttachFile
> 
> However, this is obviously not suitable for JavaDocs. I can create
> accounts for anyone who needs access to upload files (scp and sftp
only
> - sorry, no ftp). Alternatively, we could stick these files on
> http://mockobjects.sourceforge.net and cross link (which will save the
> hassle of keeping these accounts updated).
> 

hum... a good idea I hadn't thought about :-). It makes sense as the sf
area is for code and javadoc is close to the code. I'd be +1 for that
solution as it is also simpler.

Thanks
-Vincent

> Either way's good for me - what would you prefer?
> 
> cheers
> -joe
> 

RE: [MO-java-dev] Is IsEqual testing for equality in the right order?

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

There is a subtle difference when testing - sometimes you want to be able to
pass in an object (a mock version - where if there was no interface it
should still act as equal).

This implies that it is preferable to write equals as

equals(obj o) {
 return o.equals(this);
}

I  don't think we have this issue in the dynamic version and as nat points
out the constraints are written to handle this - but the older version did
have this issue sometimes...

Ignore this if its confusing - its just something that I remember from years
ago.


Tim
> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Nat Pryce
> Sent: 02 June 2003 23:09
> To: Vincent Tence; 'Mockobjects-Java-Dev'
> Subject: Re: [MO-java-dev] Is IsEqual testing for equality in the right
> order?
>
>
> > According to the Java equals protocol, the expressions
> arg.equals(_object)
> > and _object.equals(arg) must act the same, so it makes no
> difference.  If
> > the two expressions act differently, then that is a bug in the
> > implementation of the class of arg or _object.
>
> I should have also said: if you want different behaviour, you can always
> write a new constraint by implementing the Constraint interface.  This is
> exactly the situation that the Constraint interface was designed for.
>
> Cheers,
>             Nat.
>
> _______________________
> Dr. Nathaniel Pryce
> B13media Ltd.
> http://www.b13media.com
> +44 (0)7712 526 661
>
>
> ----- Original Message -----
> From: "Nat Pryce" <nat...@b1...>
> To: "Vincent Tence" <Vin...@ge...>; "'Mockobjects-Java-Dev'"
> <moc...@li...>
> Sent: Monday, June 02, 2003 11:07 PM
> Subject: Re: [MO-java-dev] Is IsEqual testing for equality in the right
> order?
>
>
> >
> > Cheers,
> >             Nat.
> > _______________________
> > Dr. Nathaniel Pryce
> > B13media Ltd.
> > http://www.b13media.com
> > +44 (0)7712 526 661
> >
> > ----- Original Message -----
> > From: "Vincent Tence" <Vin...@ge...>
> > To: "'Mockobjects-Java-Dev'"
> <moc...@li...>
> > Sent: Monday, June 02, 2003 10:57 PM
> > Subject: [MO-java-dev] Is IsEqual testing for equality in the
> right order?
> >
> >
> > > Hi,
> > >
> > > I noticed that the IsEqual constraint tests for equality by comparing
> the
> > > expected value against the actual value. IIRC it used to be the other
> way
> > > around with "static" mocks - i.e. expected.equals(actual) -
> so you could
> > > deal with legacy code not implementing equals correctly. It has helped
> me
> > in
> > > a number of situtations. Any reason why this has changed?
> > >
> > > Extract from IsEqual :
> > >
> > >     public boolean eval( Object arg ) {
> > >     if(arg instanceof Object[]) {
> > >     arg = Arrays.asList((Object[])arg);
> > >     }
> > >         return arg.equals(_object);
> > >     }
> > >
> > > It could be _object.equals(arg) or am I missing something?
> > >
> > > Thanks,
> > > Vincent
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: eBay
> > > Get office equipment for less on eBay!
> > > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> > > _______________________________________________
> > > Mockobjects-java-dev mailing list
> > > Moc...@li...
> > > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> >
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003

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

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

Vincent Massol wrote:

>Now that the mockobjects web site is a pure wiki, how do we upload
>things like the javadoc? 
>
>(Joe, is there an area that you could make available for that on the
>server hosting the wiki?)
>
>Thanks
>-Vincent
>  
>
Good point.

It's possible to upload individual files to the wiki (inline images, 
downloadables and even through a funky online diagram editor). See 
http://www.mockobjects.com/wiki/HelpOnActions/AttachFile

However, this is obviously not suitable for JavaDocs. I can create 
accounts for anyone who needs access to upload files (scp and sftp only 
- sorry, no ftp). Alternatively, we could stick these files on 
http://mockobjects.sourceforge.net and cross link (which will save the 
hassle of keeping these accounts updated).

Either way's good for me - what would you prefer?

cheers
-joe