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

Re: [Mockobjects-java-users] Directory structure

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

PiA+IHVzZSAnc3JjJyBpbnN0ZWFkIG9mICdqYXZhJy4gSXQncyBhbGwgamF2YS4NCj4gDQo+IHll
cywgc3VyZSBidXQgdGhlcmUgaXMgYWxyZWFkeSBhIHNyYyBkaXJlY3RvcnkgLi4uIEkgYW0gYWN0
dWFsbHkgbm90DQo+IGludmVudGluZyBoZXJlLCBqdXN0IHVzaW5nIGEgc3RhbmRhcmQgY29udmVu
dGlvbiB0aGF0IEkgaGF2ZSBzZWVuIGFsbCBvdmVyDQo+IHRoZSBwbGFjZSBpbiBvcGVuIHNvdXJj
ZSBqYXZhIGxhbmQuDQoNCll1ay4gT0sNCg0KPiB1dGlsIGlzIGluIGphdmEvY29tL21vY2tvYmpl
Y3RzL3V0aWwsIHJpZ2h0ID8NCg0KeWVzDQoNCj4gb2ssIHdlIGtlZXAgdGhpcyBvbmUuIFdlJ2xs
IGFkZHJlc3MgdGhlIGlzc3VlIGlmIGl0IGJlY29tZXMgb25lLCBsYXRlciAuLi4NCj4gOikNCg0K
WUFHTkkgIQ0KDQoNCg==

Re: [Mockobjects-java-users] Directory structure

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

----- Original Message -----
From: "Steve Freeman" <st...@m3...>
To: <moc...@li...>
Sent: Wednesday, August 22, 2001 11:14 PM
Subject: Re: [Mockobjects-java-users] Directory structure


> From: "Vincent Massol" <vm...@oc...>
> > Can I modify the directory structure to be :
> >
> > src
> >   |_ core
> >     |_ java
> >       |_ com/mockobjects/[...]
> >     |_ tests
> >       |_ com/mockobjects/[...]
> >     |_ examples
> >       |_ com/mockobjects/examples/[...]
> >
> > The core only contains the core classes (expectation lists, ...) and is
> > useful for projects like Mock Maker and others that do not need the mock
> > implementations. The distributable will be "mockobjects-java-core.jar"
>
> use 'src' instead of 'java'. It's all java.

yes, sure but there is already a src directory ... I am actually not
inventing here, just using a standard convention that I have seen all over
the place in open source java land.

>
> don't forget util. This library is unlikely to include examples as the
unit tests will cover that.

util is in java/com/mockobjects/util, right ?

>
> >   |_ standard (or a better name)
> >     |_ java
> >     |_ tests
> >     |_ examples
> > For the sub directories under the java directory, we have several
choices :
>
> > choice 1 : use the same package as the classes to mock. For example, the
> > mock for HttpURLConnection will be in the java.net package. the mock for
> > HttpServletRequest will be in javax.servlet.http, ... There is little
risk
> > that there will a name collision (as we name our classes MockXXX, but it
> > still exists)
>
> can't do that. clashes with VisualAge.

:(

>
> > choice 2 : use the java hierarchy but prefix by our domain name. For
> > example, MockHttpServletRequest will be in the
> > com.mockobjects.javax.servlet.http package
>
> too long

yes, I agree, but consistent and give us room ...

>
> > choice 3: keep the existing packages, i.e. no rules.
MockHttpServletRequest
> > will be in com.mockobjects.servlet
>
> Actually, this seems to work quite well as we tend to mock up only a
subset of the types from each library, and it makes the locations really
obvious. Also, it avoids excessive imports into test classes.

ok, we keep this one. We'll address the issue if it becomes one, later ...
:)

>
> An alternative might be mock.sql.*; mock.ibm.this.that.*
>
> > The "standard " directory will provides mock implementations for the
java
> > platform (java.* and javax.* packages). The distributable will be
> > "mockobjects-java-standard.jar"
>
> I would include the core classes in this jar to avoid excessive
classpaths, and not include the tests or examples.

ok, good idea.

>
> >   |_ extensions
> >     |_ atg
> >       |_ java
> >       |_ tests
> >       |_ examples
> >     |_ ...
> >
> > Each extension will be delivered as a separate jar. For example the atg
> > mocks will be delivered as : "mockobjects-java-atg.jar"
>
> We might want just to deliver the source code. We can't compile these
without the various 3rd party libraries and it could all get very
complicated.

ok, agreed, replace .jar by .zip

>
> > I'd like to do that ASAP ... so please hurry to comment if you don't
agree
>
> If you're going to make changes that put the connextra codebase at risk,
we'd better stick to the current packaging -- unless you can get agreement
from Tim.

As we won't change the package name, it won't put anyone at risk ...
-Vincent

Re: [Mockobjects-java-users] Directory structure

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

RnJvbTogIlZpbmNlbnQgTWFzc29sIiA8dm1hc3NvbEBvY3RvLmNvbT4NCj4gQ2FuIEkgbW9kaWZ5
IHRoZSBkaXJlY3Rvcnkgc3RydWN0dXJlIHRvIGJlIDoNCj4gDQo+IHNyYw0KPiAgIHxfIGNvcmUN
Cj4gICAgIHxfIGphdmENCj4gICAgICAgfF8gY29tL21vY2tvYmplY3RzL1suLi5dDQo+ICAgICB8
XyB0ZXN0cw0KPiAgICAgICB8XyBjb20vbW9ja29iamVjdHMvWy4uLl0NCj4gICAgIHxfIGV4YW1w
bGVzDQo+ICAgICAgIHxfIGNvbS9tb2Nrb2JqZWN0cy9leGFtcGxlcy9bLi4uXQ0KPiANCj4gVGhl
IGNvcmUgb25seSBjb250YWlucyB0aGUgY29yZSBjbGFzc2VzIChleHBlY3RhdGlvbiBsaXN0cywg
Li4uKSBhbmQgaXMNCj4gdXNlZnVsIGZvciBwcm9qZWN0cyBsaWtlIE1vY2sgTWFrZXIgYW5kIG90
aGVycyB0aGF0IGRvIG5vdCBuZWVkIHRoZSBtb2NrDQo+IGltcGxlbWVudGF0aW9ucy4gVGhlIGRp
c3RyaWJ1dGFibGUgd2lsbCBiZSAibW9ja29iamVjdHMtamF2YS1jb3JlLmphciINCg0KdXNlICdz
cmMnIGluc3RlYWQgb2YgJ2phdmEnLiBJdCdzIGFsbCBqYXZhLg0KDQpkb24ndCBmb3JnZXQgdXRp
bC4gVGhpcyBsaWJyYXJ5IGlzIHVubGlrZWx5IHRvIGluY2x1ZGUgZXhhbXBsZXMgYXMgdGhlIHVu
aXQgdGVzdHMgd2lsbCBjb3ZlciB0aGF0LiANCg0KPiAgIHxfIHN0YW5kYXJkIChvciBhIGJldHRl
ciBuYW1lKQ0KPiAgICAgfF8gamF2YQ0KPiAgICAgfF8gdGVzdHMNCj4gICAgIHxfIGV4YW1wbGVz
DQo+IEZvciB0aGUgc3ViIGRpcmVjdG9yaWVzIHVuZGVyIHRoZSBqYXZhIGRpcmVjdG9yeSwgd2Ug
aGF2ZSBzZXZlcmFsIGNob2ljZXMgOg0KDQo+IGNob2ljZSAxIDogdXNlIHRoZSBzYW1lIHBhY2th
Z2UgYXMgdGhlIGNsYXNzZXMgdG8gbW9jay4gRm9yIGV4YW1wbGUsIHRoZQ0KPiBtb2NrIGZvciBI
dHRwVVJMQ29ubmVjdGlvbiB3aWxsIGJlIGluIHRoZSBqYXZhLm5ldCBwYWNrYWdlLiB0aGUgbW9j
ayBmb3INCj4gSHR0cFNlcnZsZXRSZXF1ZXN0IHdpbGwgYmUgaW4gamF2YXguc2VydmxldC5odHRw
LCAuLi4gVGhlcmUgaXMgbGl0dGxlIHJpc2sNCj4gdGhhdCB0aGVyZSB3aWxsIGEgbmFtZSBjb2xs
aXNpb24gKGFzIHdlIG5hbWUgb3VyIGNsYXNzZXMgTW9ja1hYWCwgYnV0IGl0DQo+IHN0aWxsIGV4
aXN0cykNCg0KY2FuJ3QgZG8gdGhhdC4gY2xhc2hlcyB3aXRoIFZpc3VhbEFnZS4NCg0KPiBjaG9p
Y2UgMiA6IHVzZSB0aGUgamF2YSBoaWVyYXJjaHkgYnV0IHByZWZpeCBieSBvdXIgZG9tYWluIG5h
bWUuIEZvcg0KPiBleGFtcGxlLCBNb2NrSHR0cFNlcnZsZXRSZXF1ZXN0IHdpbGwgYmUgaW4gdGhl
DQo+IGNvbS5tb2Nrb2JqZWN0cy5qYXZheC5zZXJ2bGV0Lmh0dHAgcGFja2FnZQ0KDQp0b28gbG9u
Zw0KIA0KPiBjaG9pY2UgMzoga2VlcCB0aGUgZXhpc3RpbmcgcGFja2FnZXMsIGkuZS4gbm8gcnVs
ZXMuIE1vY2tIdHRwU2VydmxldFJlcXVlc3QNCj4gd2lsbCBiZSBpbiBjb20ubW9ja29iamVjdHMu
c2VydmxldA0KDQpBY3R1YWxseSwgdGhpcyBzZWVtcyB0byB3b3JrIHF1aXRlIHdlbGwgYXMgd2Ug
dGVuZCB0byBtb2NrIHVwIG9ubHkgYSBzdWJzZXQgb2YgdGhlIHR5cGVzIGZyb20gZWFjaCBsaWJy
YXJ5LCBhbmQgaXQgbWFrZXMgdGhlIGxvY2F0aW9ucyByZWFsbHkgb2J2aW91cy4gQWxzbywgaXQg
YXZvaWRzIGV4Y2Vzc2l2ZSBpbXBvcnRzIGludG8gdGVzdCBjbGFzc2VzLg0KDQpBbiBhbHRlcm5h
dGl2ZSBtaWdodCBiZSBtb2NrLnNxbC4qOyBtb2NrLmlibS50aGlzLnRoYXQuKg0KDQo+IFRoZSAi
c3RhbmRhcmQgIiBkaXJlY3Rvcnkgd2lsbCBwcm92aWRlcyBtb2NrIGltcGxlbWVudGF0aW9ucyBm
b3IgdGhlIGphdmENCj4gcGxhdGZvcm0gKGphdmEuKiBhbmQgamF2YXguKiBwYWNrYWdlcykuIFRo
ZSBkaXN0cmlidXRhYmxlIHdpbGwgYmUNCj4gIm1vY2tvYmplY3RzLWphdmEtc3RhbmRhcmQuamFy
Ig0KDQpJIHdvdWxkIGluY2x1ZGUgdGhlIGNvcmUgY2xhc3NlcyBpbiB0aGlzIGphciB0byBhdm9p
ZCBleGNlc3NpdmUgY2xhc3NwYXRocywgYW5kIG5vdCBpbmNsdWRlIHRoZSB0ZXN0cyBvciBleGFt
cGxlcy4gDQogDQo+ICAgfF8gZXh0ZW5zaW9ucw0KPiAgICAgfF8gYXRnDQo+ICAgICAgIHxfIGph
dmENCj4gICAgICAgfF8gdGVzdHMNCj4gICAgICAgfF8gZXhhbXBsZXMNCj4gICAgIHxfIC4uLg0K
PiANCj4gRWFjaCBleHRlbnNpb24gd2lsbCBiZSBkZWxpdmVyZWQgYXMgYSBzZXBhcmF0ZSBqYXIu
IEZvciBleGFtcGxlIHRoZSBhdGcNCj4gbW9ja3Mgd2lsbCBiZSBkZWxpdmVyZWQgYXMgOiAibW9j
a29iamVjdHMtamF2YS1hdGcuamFyIg0KDQpXZSBtaWdodCB3YW50IGp1c3QgdG8gZGVsaXZlciB0
aGUgc291cmNlIGNvZGUuIFdlIGNhbid0IGNvbXBpbGUgdGhlc2Ugd2l0aG91dCB0aGUgdmFyaW91
cyAzcmQgcGFydHkgbGlicmFyaWVzIGFuZCBpdCBjb3VsZCBhbGwgZ2V0IHZlcnkgY29tcGxpY2F0
ZWQuDQoNCj4gSSdkIGxpa2UgdG8gZG8gdGhhdCBBU0FQIC4uLiBzbyBwbGVhc2UgaHVycnkgdG8g
Y29tbWVudCBpZiB5b3UgZG9uJ3QgYWdyZWUNCg0KSWYgeW91J3JlIGdvaW5nIHRvIG1ha2UgY2hh
bmdlcyB0aGF0IHB1dCB0aGUgY29ubmV4dHJhIGNvZGViYXNlIGF0IHJpc2ssIHdlJ2QgYmV0dGVy
IHN0aWNrIHRvIHRoZSBjdXJyZW50IHBhY2thZ2luZyAtLSB1bmxlc3MgeW91IGNhbiBnZXQgYWdy
ZWVtZW50IGZyb20gVGltLg0KDQoNCg==

[Mockobjects-java-users] Directory structure

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

Can I modify the directory structure to be :

src
  |_ core
    |_ java
      |_ com/mockobjects/[...]
    |_ tests
      |_ com/mockobjects/[...]
    |_ examples
      |_ com/mockobjects/examples/[...]

The core only contains the core classes (expectation lists, ...) and is
useful for projects like Mock Maker and others that do not need the mock
implementations. The distributable will be "mockobjects-java-core.jar"

  |_ standard (or a better name)
    |_ java
    |_ tests
    |_ examples

For the sub directories under the java directory, we have several choices :

choice 1 : use the same package as the classes to mock. For example, the
mock for HttpURLConnection will be in the java.net package. the mock for
HttpServletRequest will be in javax.servlet.http, ... There is little risk
that there will a name collision (as we name our classes MockXXX, but it
still exists)

choice 2 : use the java hierarchy but prefix by our domain name. For
example, MockHttpServletRequest will be in the
com.mockobjects.javax.servlet.http package

choice 3: keep the existing packages, i.e. no rules. MockHttpServletRequest
will be in com.mockobjects.servlet

The "standard " directory will provides mock implementations for the java
platform (java.* and javax.* packages). The distributable will be
"mockobjects-java-standard.jar"

  |_ extensions
    |_ atg
      |_ java
      |_ tests
      |_ examples
    |_ ...

Each extension will be delivered as a separate jar. For example the atg
mocks will be delivered as : "mockobjects-java-atg.jar"

Any comment ?
I'd like to do that ASAP ... so please hurry to comment if you don't agree
... :)

Thanks
-Vincent

Re: [Mockobjects-java-users] [Proposal] List of tasks for release 0.02

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

Sorry this should have been posted to the -dev mailing list (I'm reposting)
Users please ignore ... :-)

----- Original Message -----
From: "Vincent Massol" <vm...@oc...>
To: <moc...@li...>
Sent: Wednesday, August 15, 2001 3:07 PM
Subject: [Mockobjects-java-users] [Proposal] List of tasks for release 0.02


> Here is a list of tasks that I propose for Release 0.02. Can you please
> state your agreement and others that would like to see. I'll wait for your
> approval before entering them in the todo page :
>
> T1 - [doc] What are MockObjects?
> T2 - [doc] Difference between MO and Stubs ?
> T3 - [doc] Goal page that explains short term and long term goals of the
> project
> T4 - [doc] Coding conventions (in a "Developer" menu)
> T5 - [doc] Features page
> T6 - [doc] Release process page (in a "Developer" menu)
> T7 - [code] add javadoc to all code where needed + add version number to
> sources (@version @version@) + packages.html + overview.html
> T8 - [code] Code aligned with coding conventions (and MO naming
conventions
> already present on the web site)
> T9 - [build] finalized build process (still need to finalize directory
> structure + manage examples + manage extensions)
>
> These are the "mnimum" set of task that is can we before the release 0.02.
>
> Tell me also if you wish to volunteer for a given task. There can be
several
> persons volunteering for the same task.
>
> I volunteer for T2, T4, T6, T9.
>
> Thanks
> -Vincent
>
>
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> http://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
>

Re: [Mockobjects-java-users] [IMPORTANT] Release Process

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

Sorry this should have been posted to the -dev mailing list (I'm reposting)
Users please ignore ... :-)

----- Original Message -----
From: "Vincent Massol" <vm...@oc...>
To: <moc...@li...>
Sent: Wednesday, August 15, 2001 2:58 PM
Subject: [Mockobjects-java-users] [IMPORTANT] Release Process


> I went to the MockObjects web site .... and noticed that version 0.01 was
> released ! <argh>
>
> We'll consider this first release as a try .... and forget about it. Now I
> would like use to agree on the release process. Can you review all the
> following point and tell me whether you agree or not so that we can reach
a
> consensus. Once this is done we'll put a page on the web site explaining
the
> release process. Thanks
>
> P1 - Releasing a version is a community action that we all need to decide
> together (the committers of the project). Before *any* release, we will
need
> to agree on doing a release. This entails sending a message on the mailing
> list asking for a vote on the release (I propose to use the Apache Jakarta
> system for voting : http://jakarta.apache.org/site/decisions.html).
>
> P2 - Long before any release, we need to define what will go into that
> release, i.e. the list of tasks that need to be performed *prior* to that
> release. These tasks will be listed in the
> http://mockobjects.sourceforge.net/todo.html (todo.xml file in CVS). Tasks
> can be proposed on the mailing list (such as the mail I sent on 1st of
> august, entitled "[Proposal] Roadmap". Unfortunately noone answered so
these
> tasks were not entered in the todo page. I'm still waiting for an ageement
> before entering them !).
>
> P3 - The changes page (http://mockobjects.sourceforge.net/changes.html,
> changes.xml file in CVS) need to be up to date at any time. The goal of
this
> page is not to described fine-grained changes in CVS like "I have
corrected
> a typo" but rather to advertise changes that are useful to end users (for
> example: "Improved the Mailing-list example by ..."). As it is very hard
to
> remember everything that everyone has done, it is mandatory to fill this
> page as we do the modifications and not to wait till the release to fill
it.
> At the current time, this page is *NOT* up to date.
>
> P4 - Check list of administrative tasks to perform before any release :
>
> A1 - Agree on a release (see P1)
> A2 - Designate a release manager for the current release to perform
> A3 - Ensure that no one is working on any part of the files (code freeze).
> This is done by posting a mail on the list asking for a code freeze.
> A4 - Verify that the todo.html files is up to date
> A5 - Verify that the changes.html file is up to date
> A6 - Verify that the features page is up to date and includes all features
> available in all releases + the new ones of this release. Note: This page
> does not currently exist but we should create it quickly. This is the page
> that persons will look at the most often to see what features the Mock
> Objects project has.
> A7 - Verify that the news items on the index page are up to date (major
> announcement should be listed there, a release is a major announcement - A
> news item should be added that says which version has been released with a
> link pointing to the changes page)
> A8 - Perform a Ant build 'dist' on the release manager's machine to ensure
> everything build fine including the tests, web site generation, ...
> A9 - Tag CVS (with the name MO_0_01_RELEASE - example for release 0.01)
> A10- Publish the distributables files to SF. In the release note area of
SF,
> put a link to the changes page
> A11- Increase the version number indicated in the build.xml file by 1 (for
> example, after 0.01, put 0.02)
> A12- Write a release announcement in the news area of SF (with a link to
the
> changes page)
> A13- Send a message to mockobjects-java-user and -dev mailing lists to
> announce the availability of the release
> A14- (optional) Send announcements to other mailing-lists (XP mailing
lists
> on yahoogroups, JUnit mailing list) and web sites (junit.org,
objectmentor,
> ...)
>
> ... then relax ! ;-)
>
> I propose that we start doing this immediatly and follow this process for
> the 0.02 release.
> Thanks
> -Vincent
>
>
>
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> http://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
>

[Mockobjects-java-users] [Proposal] List of tasks for release 0.02

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

Here is a list of tasks that I propose for Release 0.02. Can you please
state your agreement and others that would like to see. I'll wait for your
approval before entering them in the todo page :

T1 - [doc] What are MockObjects?
T2 - [doc] Difference between MO and Stubs ?
T3 - [doc] Goal page that explains short term and long term goals of the
project
T4 - [doc] Coding conventions (in a "Developer" menu)
T5 - [doc] Features page
T6 - [doc] Release process page (in a "Developer" menu)
T7 - [code] add javadoc to all code where needed + add version number to
sources (@version @version@) + packages.html + overview.html
T8 - [code] Code aligned with coding conventions (and MO naming conventions
already present on the web site)
T9 - [build] finalized build process (still need to finalize directory
structure + manage examples + manage extensions)

These are the "mnimum" set of task that is can we before the release 0.02.

Tell me also if you wish to volunteer for a given task. There can be several
persons volunteering for the same task.

I volunteer for T2, T4, T6, T9.

Thanks
-Vincent

[Mockobjects-java-users] [IMPORTANT] Release Process

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

I went to the MockObjects web site .... and noticed that version 0.01 was
released ! <argh>

We'll consider this first release as a try .... and forget about it. Now I
would like use to agree on the release process. Can you review all the
following point and tell me whether you agree or not so that we can reach a
consensus. Once this is done we'll put a page on the web site explaining the
release process. Thanks

P1 - Releasing a version is a community action that we all need to decide
together (the committers of the project). Before *any* release, we will need
to agree on doing a release. This entails sending a message on the mailing
list asking for a vote on the release (I propose to use the Apache Jakarta
system for voting : http://jakarta.apache.org/site/decisions.html).

P2 - Long before any release, we need to define what will go into that
release, i.e. the list of tasks that need to be performed *prior* to that
release. These tasks will be listed in the
http://mockobjects.sourceforge.net/todo.html (todo.xml file in CVS). Tasks
can be proposed on the mailing list (such as the mail I sent on 1st of
august, entitled "[Proposal] Roadmap". Unfortunately noone answered so these
tasks were not entered in the todo page. I'm still waiting for an ageement
before entering them !).

P3 - The changes page (http://mockobjects.sourceforge.net/changes.html,
changes.xml file in CVS) need to be up to date at any time. The goal of this
page is not to described fine-grained changes in CVS like "I have corrected
a typo" but rather to advertise changes that are useful to end users (for
example: "Improved the Mailing-list example by ..."). As it is very hard to
remember everything that everyone has done, it is mandatory to fill this
page as we do the modifications and not to wait till the release to fill it.
At the current time, this page is *NOT* up to date.

P4 - Check list of administrative tasks to perform before any release :

A1 - Agree on a release (see P1)
A2 - Designate a release manager for the current release to perform
A3 - Ensure that no one is working on any part of the files (code freeze).
This is done by posting a mail on the list asking for a code freeze.
A4 - Verify that the todo.html files is up to date
A5 - Verify that the changes.html file is up to date
A6 - Verify that the features page is up to date and includes all features
available in all releases + the new ones of this release. Note: This page
does not currently exist but we should create it quickly. This is the page
that persons will look at the most often to see what features the Mock
Objects project has.
A7 - Verify that the news items on the index page are up to date (major
announcement should be listed there, a release is a major announcement - A
news item should be added that says which version has been released with a
link pointing to the changes page)
A8 - Perform a Ant build 'dist' on the release manager's machine to ensure
everything build fine including the tests, web site generation, ...
A9 - Tag CVS (with the name MO_0_01_RELEASE - example for release 0.01)
A10- Publish the distributables files to SF. In the release note area of SF,
put a link to the changes page
A11- Increase the version number indicated in the build.xml file by 1 (for
example, after 0.01, put 0.02)
A12- Write a release announcement in the news area of SF (with a link to the
changes page)
A13- Send a message to mockobjects-java-user and -dev mailing lists to
announce the availability of the release
A14- (optional) Send announcements to other mailing-lists (XP mailing lists
on yahoogroups, JUnit mailing list) and web sites (junit.org, objectmentor,
...)

... then relax ! ;-)

I propose that we start doing this immediatly and follow this process for
the 0.02 release.
Thanks
-Vincent

Re: [Mockobjects-java-users] Examples

[<ch...@fr...>]

I'll have a look.
Cheers
  ----- Original Message -----=20
  From: Vincent Massol=20
  To: moc...@li...=20
  Sent: Wednesday, August 15, 2001 10:54 AM
  Subject: Re: [Mockobjects-java-users] Examples


  ok, then download the distribution, there are plenty of examples.
  Thanks
  -Vincent
    ----- Original Message -----=20
    From: ch...@fr...=20
    To: moc...@li...=20
    Sent: Wednesday, August 15, 2001 10:42 AM
    Subject: Re: [Mockobjects-java-users] Examples


    All I want is a really simple working example that I can compile and =
run. This will help me to visualise how the classes within the =
mockobject packages are used.

    Thanks
      ----- Original Message -----=20
      From: Vincent Massol=20
      To: moc...@li...=20
      Sent: Wednesday, August 15, 2001 10:34 AM
      Subject: Re: [Mockobjects-java-users] Examples


      I Chung,

      Thank you for your interest in Mock Objects !=20
      This is still a work in progress ... We are 
currently working hard =
on the documentation as we agree with your comment that it is the weak =
point ...

      However, the best documentation are examples and these are =
available as part of the distribution. The latest available released =
distribution is 0.0.09. Have a look and post any question you have here. =
We'll be happy to answer them.

      We are also interested by your feedback. You said you don't find =
the doc useful. What kind of doc would you like to see first so that we =
can concentrate our efforts on that.

      Thanks
      -Vincent
        ----- Original Message -----=20
        From: ch...@fr...=20
        To: moc...@li...=20
        Sent: Wednesday, August 15, 2001 10:00 AM
        Subject: [Mockobjects-java-users] Examples


        Hi are there any example s on how to use Mock Objects. I had a =
look at the documents but don't find it very useful.

Re: [Mockobjects-java-users] Examples

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

ok, then download the distribution, there are plenty of examples.
Thanks
-Vincent
  ----- Original Message -----=20
  From: ch...@fr...=20
  To: moc...@li...=20
  Sent: Wednesday, August 15, 2001 10:42 AM
  Subject: Re: [Mockobjects-java-users] Examples


  All I want is a really simple working example that I can compile and =
run. This will help me to visualise how the classes within the =
mockobject packages are used.

  Thanks
    ----- Original Message -----=20
    From: Vincent Massol=20
    To: moc...@li...=20
    Sent: Wednesday, August 15, 2001 10:34 AM
    Subject: Re: [Mockobjects-java-users] Examples


    I Chung,

    Thank you for your interest in Mock Objects !=20
    This is still a work in progress ... We are currently working hard =
on the documentation as we agree with your comment that it is the weak =
point ...

    However, the best documentation are examples and these are available =
as part of the distribution. The latest available released distribution =
is 0.0.09. Have a look and post any question you have here. We'll be =
happy to answer them.

    We are also interested by your feedback. You said you don't find the =
doc useful. What kind of doc would you like to see first so that we can =
concentrate our efforts on that.

    Thanks
    -Vincent
      ----- Original Message -----=20
      From: ch...@fr...=20
      To: moc...@li...=20
      Sent: Wednesday, August 15, 2001 10:00 AM
      Subject: [Mockobjects-java-users] Examples


      Hi are there any example s on how to use Mock Objects. I had a =
look at the documents but don't find it very useful.

Re: [Mockobjects-java-users] Examples

[<ch...@fr...>]

All I want is a really simple working example that I can compile and =
run. This will help me to visualise how the classes within the =
mockobject packages are used.

Thanks
  ----- Original Message -----=20
  From: Vincent Massol=20
  To: moc...@li...=20
  Sent: Wednesday, August 15, 2001 10:34 AM
  Subject: Re: [Mockobjects-java-users] Examples


  I Chung,

  Thank you for your interest in Mock Objects !
  This is still a work in progress ... We are currently working hard on =
the documentation as we agree with your comment that it is the weak =
point ...

  However, the best documentation are examples and these are available =
as part of the distribution. The latest available released distribution =
is 0.0.09. Have a look and post any question you have here. We'll be =
happy to answer them.

  We are also interested by your feedback. You said you don't find the =
doc useful. What kind of doc would you like to see first so that we can =
concentrate our efforts on that.

  Thanks
  -Vincent
    ----- Original Message -----=20
    From: ch...@fr...=20
    To: moc...@li...=20
    Sent: Wednesda
y, August 15, 2001 10:00 AM
    Subject: [Mockobjects-java-users] Examples


    Hi are there any examples on how to use Mock Objects. I had a look =
at the documents but don't find it very useful.

Re: [Mockobjects-java-users] Examples

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

I Chung,

Thank you for your interest in Mock Objects !
This is still a work in progress ... We are currently working hard on =
the documentation as we agree with your comment that it is the weak =
point ...

However, the best documentation are examples and these are available as =
part of the distribution. The latest available released distribution is =
0.0.09. Have a look and post any question you have here. We'll be happy =
to answer them.

We are also interested by your feedback. You said you don't find the doc =
useful. What kind of doc would you like to see first so that we can =
concentrate our efforts on that.

Thanks
-Vincent
  ----- Original Message -----=20
  From: ch...@fr...=20
  To: moc...@li...=20
  Sent: Wednesday, August 15, 2001 10:00 AM
  Subject: [Mockobjects-java-users] Examples


  Hi are there any examples on how to use Mock Objects. I had a look at =
the documents but don't find it very useful.

[Mockobjects-java-users] Examples

[<ch...@fr...>]

Hi are there any examples on how to use Mock Objects. I had a look at =
the documents but don't find it very useful.

Re: [Mockobjects-java-users] Re: Mockobjects-java-users -- confirmation of subscription -- request 644812

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

Hi Paul,

----- Original Message -----
From: "Paul S. Kilroy" <pk...@ch...>
To: <moc...@li...>
Sent: Monday, August 13, 2001 6:02 AM
Subject: [Mockobjects-java-users] Re: Mockobjects-java-users -- confirmation
of subscription -- request 644812


> Just poking around a bit...
>
> If someone has a chance, you they fix the "API Reference" link on the
> homepage?

oops ... you're right ... I think we'll remove it, do some clean up of
javadoc comments and add it again later ... :)

>
> Also, searching the archives did not work for me.

you were out of luck .... I just tried it and it seems to work again ...
when you have some time, tell me if it works for you.

>
> Thanks
Thanks
-Vincent

[Mockobjects-java-users] Re: Mockobjects-java-users -- confirmation of subscription -- request 644812

[Paul S. K. <pk...@ch...>]

Just poking around a bit...

If someone has a chance, you they fix the "API Reference" link on the 
homepage?

Also, searching the archives did not work for me.

Thanks

Paul

Re: [Mockobjects-java-users] Advantage for In-Container vs Mock ?

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

----- Original Message -----
From: "Thomas Calivera" <ald...@ne...>
To: <moc...@li...>;
<cac...@ja...>
Sent: Thursday, August 09, 2001 7:23 PM
Subject: Re: [Mockobjects-java-users] Advantage for In-Container vs Mock ?


> Vincent
>
> "fancy name ! I am now wiser than before ... :)"
>
> Upon rereading that, I can only conclude that my inner academic made a
> stealthy strike before the send command. :)
>
> "I'm still not convinced of the advantage of these inner classes of yours
> ...
> I don't see what advanatges it brings ... Because anyway you need an
> implementation of the mock (be it static or dynamic). Now what remains is
to
> define your expectation on the mock object and this is easily done by use
> method calls to setExpectedXXX()-like methods. Something I am missing ?"
>
> With a proxy, you generally only need to mock a couple specific methods
> rather than the whole interface. If an interface does not exist, then what
> are you going to do without inner classes to mock specific methods an
> implementation class?

I like the dynamic proxy because it enables to skip the static mock
implementation generation step. Even if you don't have an interface you can
still extend a class. The idea that the Mock Objects has been developing is
that the actual mock implementation could be generated because they do not
contain any logic code. For example, for each method XXX in the interface of
class to mock, a generation process could produce the following methods :

MockYYY.java

setActualValueXXX()
setExpectedValueXXX()
setActualExceptionXXX()
XXX()

And it can generate a verify() method for each mock class which will check
all setExpected*() methods.

so that it is up to the writer of the test case to say what he expects of
the call to XXX(), as in :

public void testSomething()
{
  MockYYY mock = new MockYYY();
  mock.setActualValueXXX("text/html");
  mock.setActualValueZZZ(true);
...
  // set the expectations on the mock object (if need be)
  mock.setExpectedValueAAA("something");
...
  // the method to unit test that calls XXX
  // and ZZZ as part of it's logic
  String result = myObject.someMethod();
...
  // then the asserts, which can be a mix of junit asserts and
  // verifying against the expectations set on the mock object
  assertEquals("...", result);
  mock.verify();
}

Now, the only questions which is not 100% answered (at least for what I
know) is : Is that mechanism going to work in 100% of cases or are there
cases where it won't work. I'm still looking for counter examples. But I
have not put it in practice either .... I need to use MO to understand
better what would be the limitations if any ... We probably need to work on
a real life example and see how it's unit tests are addressed by MO and
Cactus. I have a project in mind that would be a perfect live example for
that. I'll make a proposition shortly on both Cactus and MO lists on the
subject.

>
>  If you have the chance, I would like to see some code that allows for the
> setExpectedXXX() methods you are referring to. Is it in the mock object
> source that I have on hand? Do you have to write a special mock class for
an
> interface to track methods calls and parameters? If so, let's reverse the
> question and ask why write a library to set and test expectations when it
is
> easily done by using features of the platform itself?
>

The idea is simply that with the above described generic mechanism there is
no need to inner classes at all. But I may be wrong and I'd like to know the
counter arguments!

> Also, I don't want to get into too much detail until I get some feedback
> about the last version of the article I posted here, but the use of inner
> classes that set outer class variables makes the use of the Verifiable
> interface unnecessary in many cases. Furthermore, when you are testing the
> method of a particular class, you can override other methods of that same
> class to check expectations on inter-class calls.
>
> Tom
-Vincent

Re: [Mockobjects-java-users] Advantage for In-Container vs Mock ?

[Thomas C. <ald...@ne...>]

Vincent

"fancy name ! I am now wiser than before ... :)"

Upon rereading that, I can only conclude that my inner academic made a
stealthy strike before the send command. :)

"I'm still not convinced of the advantage of these inner classes of yours
...
I don't see what advanatges it brings ... Because anyway you need an
implementation of the mock (be it static or dynamic). Now what remains is to
define your expectation on the mock object and this is easily done by use
method calls to setExpectedXXX()-like methods. Something I am missing ?"

With a proxy, you generally only need to mock a couple specific methods
rather than the whole interface. If an interface does not exist, then what
are you going to do without inner classes to mock specific methods an
implementation class?

 If you have the chance, I would like to see some code that allows for the
setExpectedXXX() methods you are referring to. Is it in the mock object
source that I have on hand? Do you have to write a special mock class for an
interface to track methods calls and parameters? If so, let's reverse the
question and ask why write a library to set and test expectations when it is
easily done by using features of the platform itself?

Also, I don't want to get into too much detail until I get some feedback
about the last version of the article I posted here, but the use of inner
classes that set outer class variables makes the use of the Verifiable
interface unnecessary in many cases. Furthermore, when you are testing the
method of a particular class, you can override other methods of that same
class to check expectations on inter-class calls.

Tom

Re: [Mockobjects-java-users] Advantage for In-Container vs Mock ?

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

----- Original Message -----
From: "Steve Freeman" <st...@m3...>
To: <moc...@li...>
Sent: Wednesday, August 08, 2001 10:21 PM
Subject: Re: [Mockobjects-java-users] Advantage for In-Container vs Mock ?


> > The getLocale() method is actually implemented in the Action class ...
So I
> > can see 2 ways of coping with this :
> > * Solution 1: Create a LogonActionForTest class that extends LogonAction
and
> > override the getLocale() method so that it returns what we want,
>
> the point here is that you're not testing the LogonAction class, only its
clients. My inclination would be to override _everything_ in LogonAction
with dumb mock methods. That way you're not relying on any mysterious
behaviour of the parent.
>
> We've done this for mocking up Dynamo classes.

er ... what do I test then ? :)
No, I think there is misunderstanding: what I am unit testing is the
LogonAction class itself, which is why I cannot mock it ... The class that
we are not testing is the Action class but we cannot override it as the
LogonAction is extending it. The only way is by extending the LogonAction
class and override the methods that are implemented in Action and _not_ in
LogonAction, which is what solution 1 is about.

>
> steve
-Vincent

Re: [Mockobjects-java-users] Advantage for In-Container vs Mock ?

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

PiBUaGUgZ2V0TG9jYWxlKCkgbWV0aG9kIGlzIGFjdHVhbGx5IGltcGxlbWVudGVkIGluIHRoZSBB
Y3Rpb24gY2xhc3MgLi4uIFNvIEkNCj4gY2FuIHNlZSAyIHdheXMgb2YgY29waW5nIHdpdGggdGhp
cyA6DQo+ICogU29sdXRpb24gMTogQ3JlYXRlIGEgTG9nb25BY3Rpb25Gb3JUZXN0IGNsYXNzIHRo
YXQgZXh0ZW5kcyBMb2dvbkFjdGlvbiBhbmQNCj4gb3ZlcnJpZGUgdGhlIGdldExvY2FsZSgpIG1l
dGhvZCBzbyB0aGF0IGl0IHJldHVybnMgd2hhdCB3ZSB3YW50LA0KDQp0aGUgcG9pbnQgaGVyZSBp
cyB0aGF0IHlvdSdyZSBub3QgdGVzdGluZyB0aGUgTG9nb25BY3Rpb24gY2xhc3MsIG9ubHkgaXRz
IGNsaWVudHMuIE15IGluY2xpbmF0aW9uIHdvdWxkIGJlIHRvIG92ZXJyaWRlIF9ldmVyeXRoaW5n
XyBpbiBMb2dvbkFjdGlvbiB3aXRoIGR1bWIgbW9jayBtZXRob2RzLiBUaGF0IHdheSB5b3UncmUg
bm90IHJlbHlpbmcgb24gYW55IG15c3RlcmlvdXMgYmVoYXZpb3VyIG9mIHRoZSBwYXJlbnQuIA0K
DQpXZSd2ZSBkb25lIHRoaXMgZm9yIG1vY2tpbmcgdXAgRHluYW1vIGNsYXNzZXMuDQoNCnN0ZXZl
DQoNCg==

Re: [Mockobjects-java-users] Advantage for In-Container vs Mock ?

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

----- Original Message -----
From: "Thomas Calivera" <ald...@ne...>
To: <moc...@li...>;
<cac...@ja...>
Sent: Wednesday, August 08, 2001 4:26 PM
Subject: Re: [Mockobjects-java-users] Advantage for In-Container vs Mock ?


> Vincent
>
> "The getLocale() method is actually implemented in the Action class ... So
I
> can see 2 ways of coping with this :
> * Solution 1: Create a LogonActionForTest class that extends LogonAction
and
> override the getLocale() method so that it returns what we want,"
>
> If I am following this thread correctly, I think it is useful to consider
> that, although the article I posted earlier shows how to override methods
of
> objects passed in *as parameters*, the same technique is useful in
> overriding methods of the actual test subject during testing, as I think
you
> are realizing in terms of overriding the getLocale() method.
>

yep

> At first, it feels like a violation of the normative Heisenberg
uncertainty

fancy name ! I am now wiser than before ... :)

> principle because you are *changing the class you are testing*, but unit
> testing is concerned with particular *methods*, not classes. Therefore, as
> long as you do not override the method you are testing with the anonymous
> inner class, you can actually use an anonymous inner class to redefine an
> object you are about to test, including any methods except the one you are
> testing. I can provide a code example if necessary (I need to write one
for
> the article anyway).

I'm still not convinced of the advantage of these inner classes of yours ...
I don't see what advanatges it brings ... Because anyway you need an
implementation of the mock (be it static or dynamic). Now what remains is to
define your expectation on the mock object and this is easily done by use
method calls to setExpectedXXX()-like methods. Something I am missing ?

>
> Tom
-Vincent

Re: [Mockobjects-java-users] Advantage for In-Container vs Mock ?

[Thomas C. <ald...@ne...>]

Vincent

"The getLocale() method is actually implemented in the Action class ... So I
can see 2 ways of coping with this :
* Solution 1: Create a LogonActionForTest class that extends LogonAction and
override the getLocale() method so that it returns what we want,"

If I am following this thread correctly, I think it is useful to consider
that, although the article I posted earlier shows how to override methods of
objects passed in *as parameters*, the same technique is useful in
overriding methods of the actual test subject during testing, as I think you
are realizing in terms of overriding the getLocale() method.

At first, it feels like a violation of the normative Heisenberg uncertainty
principle because you are *changing the class you are testing*, but unit
testing is concerned with particular *methods*, not classes. Therefore, as
long as you do not override the method you are testing with the anonymous
inner class, you can actually use an anonymous inner class to redefine an
object you are about to test, including any methods except the one you are
testing. I can provide a code example if necessary (I need to write one for
the article anyway).

Tom

Re: [Mockobjects-java-users] Advantage for In-Container vs Mock ?

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

After thinking a bit more, I now understand what I meant and why I said you
had to understand internally how Struts work. This is true in some cases and
stems from the fact that Struts is using Base classes instead of interfaces
and thus these base classes have some logic in them ... You'll understand
what I mean below ...

Let's take the following example :

public final class LogonAction extends Action {

    public ActionForward perform(ActionMapping mapping,
     ActionForm form,
     HttpServletRequest request,
     HttpServletResponse response)
 throws IOException, ServletException {

 // Extract attributes we will need
 Locale locale = getLocale(request);
[...]
}

The getLocale() method is actually implemented in the Action class ... So I
can see 2 ways of coping with this :
* Solution 1: Create a LogonActionForTest class that extends LogonAction and
override the getLocale() method so that it returns what we want,
* Solution 2: Read the source, to find that actually Struts looks into the
session for a variable that contains the Locale. Then, write something like

public void testXXX()
{
  mockSession.put(Action.LOCALE_KEY, <our locale>);
  myAction.perform(....);
...
}

If we use the Cactus approach, i.e. initialize ActionServlet as in real
(using the struts-config.xml file), this key will be placed by Struts
automatically in the session and we won't have to implement either solution
1 or solution 2. Note that we are *not* interested in finding out what
happens if they locale is not correctly set as Struts is supposed to handle
that and always return a valid Locale. However we are interested in finding
out that our code behaves well with different locales.

Regarding Mock Object, it seems to me that Solution 1 is more in the spriti
of MO.
Potential problems with Solution 1 :
* It will only work if our Action class is not declared final ...
* It will fail if there is some (badly written) code that verifies the class
of the Action and expects a LogonAction class (it will get a
LogonActionForTest class instead) and not a derived one.

Thoughts?
Thanks
-Vincent

----- Original Message -----
From: "Vincent Massol" <vm...@oc...>
To: <cac...@ja...>
Sent: Wednesday, August 08, 2001 3:16 PM
Subject: Re: Another point of Mock vs In-Container approach


> Let me answer some of my points ...
>
> ----- Original Message -----
> From: "Vincent Massol" <vm...@oc...>
> To: <cac...@ja...>
> Cc: <moc...@li...>
> Sent: Wednesday, August 08, 2001 1:55 PM
> Subject: Another point of Mock vs In-Container approach
>
>
> > I was thinking about unit testing Struts Actions.
> >
> > Introduction
> > ------------
> >
> > Writing a Struts Action is very simple: you simply have to provide a
> perform
> > method with the following signature :
> >
> >     public ActionForward perform(ActionMapping mapping,
> >                                  ActionForm form,
> >                                  ServletRequest request,
> >                                  ServletResponse response)
> >
> >
> > Thus, in order to use Mock Objects for unit testing your action you have
> to
> > provide mock implementations of :
> > - ActionMapping,
> > - ActionForm,
> > - ServletRequest,
> > - ServletResponse,
> > - ActionServlet : an instance of this class is provided to your action
and
> > you can use it to perforl several things. It can be set by calling the
> > setServlet(ActionServlet) method on your Action class.
> >
> > Problem
> > ---------
> >
> > The issue is that Struts initialize internally a lot of objects and put
> them
> > in different scopes : session, servlet context, request, ..., which is
> fine.
> > What it simply means is that if you want to unit test your Action class,
> > you'll need to understand in details how Struts works internally and
stuff
> > the session, context, ... with the expected values. To do that you'll
have
> > to read the source code and spend quite a lot of time (even though
Sturts
> is
> > really well designed by composition). I think this is a major hurdle for
> > using Mock Objects when your object to test is using APIs that are not
> yours
> > ... Struts is open source so it is feasible to look a the source. For
non
> > open-source framework, it is even harder ...
>
> well, I don't know what happened to me ... I must have knocked my head
> somewhere ... because this is not true at all .... Using Mock Object we
just
> need to understand what the public methods return (not how it works
> internally!) ...
>
> > The second objection is that
> > doing all this initialization takes a lot of lines of code and is a
tiring
> > process.
> >
>
> maybe true ... will need an example though to prove it...
>
> > Now, would it be easier with Cactus ? I think so ... for the following
> > reasons.
> > Here is how you would do it with Cactus :
> >
> > ActionServlet servlet = new ActionServlet();
> > servlet.init(config);
> >
>
> this is true! MO cannot beat this  ...
>
> > (you'll also have to provide a struts-config.xml file but that's fine as
> you
> > have to write one for Struts anyway).
> > that's all, Struts is initialized ! You don't need to understand how
> struts
> > works internally. Of course, you could do the same with Mock Objects but
> > you'll no longer be following the Mock Objects principles.
> >
> > Conclusion
> > -----------
> >
> > Mock Objects has limitations in the following areas :
> > - when the API to mock is not yours and especially if you don't have
> access
> > to the source code because :;
> >   - it takes time to understand how the API works internally
>
> no!
>
> >   - it takes time for every test to initialize the API environment
> properly.
>
> maybe
>
> > - it is difficult when your class to test is using an Application (as
> > opposed to a framework). A framework is for exemple a logging framework,
> it
> > contains no state and no business logic, so it is easy to mock. However
a
> > framework like Struts is actually an Application : it has state and it
has
> > logic, thus you need to understand its internal functioning to mock it.
>
> not completely sure it is wrong, maybe there is some truth in that...
>
> >
> > I would very much like to have you thoughts on that, especially if you
> don't
> > agree ! :)
>
> please don't flame me ... :)
>
> > Thanks
> >
> > -Vincent
> >
> >
>
>

Re: [Mockobjects-java-users] Advantage for In-Container vs Mock ?

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

Let me answer some of my points ...

----- Original Message -----
From: "Vincent Massol" <vm...@oc...>
To: <cac...@ja...>
Cc: <moc...@li...>
Sent: Wednesday, August 08, 2001 1:55 PM
Subject: Another point of Mock vs In-Container approach


> I was thinking about unit testing Struts Actions.
>
> Introduction
> ------------
>
> Writing a Struts Action is very simple: you simply have to provide a
perform
> method with the following signature :
>
>     public ActionForward perform(ActionMapping mapping,
>                                  ActionForm form,
>                                  ServletRequest request,
>                                  ServletResponse response)
>
>
> Thus, in order to use Mock Objects for unit testing your action you have
to
> provide mock implementations of :
> - ActionMapping,
> - ActionForm,
> - ServletRequest,
> - ServletResponse,
> - ActionServlet : an instance of this class is provided to your action and
> you can use it to perforl several things. It can be set by calling the
> setServlet(ActionServlet) method on your Action class.
>
> Problem
> ---------
>
> The issue is that Struts initialize internally a lot of objects and put
them
> in different scopes : session, servlet context, request, ..., which is
fine.
> What it simply means is that if you want to unit test your Action class,
> you'll need to understand in details how Struts works internally and stuff
> the session, context, ... with the expected values. To do that you'll have
> to read the source code and spend quite a lot of time (even though Sturts
is
> really well designed by composition). I think this is a major hurdle for
> using Mock Objects when your object to test is using APIs that are not
yours
> ... Struts is open source so it is feasible to look a the source. For non
> open-source framework, it is even harder ...

well, I don't know what happened to me ... I must have knocked my head
somewhere ... because this is not true at all .... Using Mock Object we just
need to understand what the public methods return (not how it works
internally!) ...

> The second objection is that
> doing all this initialization takes a lot of lines of code and is a tiring
> process.
>

maybe true ... will need an example though to prove it...

> Now, would it be easier with Cactus ? I think so ... for the following
> reasons.
> Here is how you would do it with Cactus :
>
> ActionServlet servlet = new ActionServlet();
> servlet.init(config);
>

this is true! MO cannot beat this  ...

> (you'll also have to provide a struts-config.xml file but that's fine as
you
> have to write one for Struts anyway).
> that's all, Struts is initialized ! You don't need to understand how
struts
> works internally. Of course, you could do the same with Mock Objects but
> you'll no longer be following the Mock Objects principles.
>
> Conclusion
> -----------
>
> Mock Objects has limitations in the following areas :
> - when the API to mock is not yours and especially if you don't have
access
> to the source code because :;
>   - it takes time to understand how the API works internally

no!

>   - it takes time for every test to initialize the API environment
properly.

maybe

> - it is difficult when your class to test is using an Application (as
> opposed to a framework). A framework is for exemple a logging framework,
it
> contains no state and no business logic, so it is easy to mock. However a
> framework like Struts is actually an Application : it has state and it has
> logic, thus you need to understand its internal functioning to mock it.

not completely sure it is wrong, maybe there is some truth in that...

>
> I would very much like to have you thoughts on that, especially if you
don't
> agree ! :)

please don't flame me ... :)

> Thanks
>
> -Vincent
>
>

[Mockobjects-java-users] Advantage for In-Container vs Mock ?

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

I was thinking about unit testing Struts Actions.

Introduction
------------

Writing a Struts Action is very simple: you simply have to provide a perform
method with the following signature :

    public ActionForward perform(ActionMapping mapping,
                                 ActionForm form,
                                 ServletRequest request,
                                 ServletResponse response)


Thus, in order to use Mock Objects for unit testing your action you have to
provide mock implementations of :
- ActionMapping,
- ActionForm,
- ServletRequest,
- ServletResponse,
- ActionServlet : an instance of this class is provided to your action and
you can use it to perforl several things. It can be set by calling the
setServlet(ActionServlet) method on your Action class.

Problem
---------

The issue is that Struts initialize internally a lot of objects and put them
in different scopes : session, servlet context, request, ..., which is fine.
What it simply means is that if you want to unit test your Action class,
you'll need to understand in details how Struts works internally and stuff
the session, context, ... with the expected values. To do that you'll have
to read the source code and spend quite a lot of time (even though Sturts is
really well designed by composition). I think this is a major hurdle for
using Mock Objects when your object to test is using APIs that are not yours
... Struts is open source so it is feasible to look a the source. For non
open-source framework, it is even harder ... The second objection is that
doing all this initialization takes a lot of lines of code and is a tiring
process.

Now, would it be easier with Cactus ? I think so ... for the following
reasons.
Here is how you would do it with Cactus :

ActionServlet servlet = new ActionServlet();
servlet.init(config);

(you'll also have to provide a struts-config.xml file but that's fine as you
have to write one for Struts anyway).
that's all, Struts is initialized ! You don't need to understand how struts
works internally. Of course, you could do the same with Mock Objects but
you'll no longer be following the Mock Objects principles.

Conclusion
-----------

Mock Objects has limitations in the following areas :
- when the API to mock is not yours and especially if you don't have access
to the source code because :;
  - it takes time to understand how the API works internally
  - it takes time for every test to initialize the API environment properly.
- it is difficult when your class to test is using an Application (as
opposed to a framework). A framework is for exemple a logging framework, it
contains no state and no business logic, so it is easy to mock. However a
framework like Struts is actually an Application : it has state and it has
logic, thus you need to understand its internal functioning to mock it.

I would very much like to have you thoughts on that, especially if you don't
agree ! :)
Thanks

-Vincent

Re: [Mockobjects-java-users] Advanced Java Patterns For Rigorous Unit Testing DRAFT

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

Hey Steve, could you please repost your answer to Thomas's question to the
list as it seems you only answered to him in private and I would like to
participate in the discussion as it seems quite interesting ... :-)
Thanks
-Vincent

----- Original Message -----
From: "Thomas Calivera" <ald...@ne...>
To: <moc...@li...>
Sent: Tuesday, August 07, 2001 5:33 PM
Subject: Re: [Mockobjects-java-users] Advanced Java Patterns For Rigorous
Unit Testing DRAFT


> Steve
>
> "just a quick point to start with. Have you looked at a recent edition of
> the mock objects library? You might want to align some of your
terminology,
> in particular the distinction between a Verifiable and a Mock"
>
> I just looked at a recent edition and very good point. Essentially, you
can
> replace the MockObject interface in the article with com.mock.Verifiable.
To
> give you some context, much of the article comes from a policy file in a
> project I am working on that started before I read your article, thus the
> inconsistencies even though your article is cited. I shall align the
> terminology in the next draft of the article.
>
> Tom
>
>
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> http://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
>