Hi Philippe,
Here is the setup I have in mind. Not only in mind, this is what I
previously did, excepted that we were using Ant.
c:/.../project/src/main/java: production code
c:/.../project/src/test/java/fixtures: fitnesse fixtures
c:/.../project/src/test/resources/specs: fitnesse pages
c:/.../tools/fitnesse/run_project.bat using fitnesse.jar from the maven
repository and having FIT_SPECS=c:/.../project/src/test/resources/specs
Then we can work like that:
-developers:
-develop the fixtures,
-use Fitnesse locally to modify Fitnesse pages as necessary and
commit
-use the FitnesseRunner class to debug their fixtures
-use maven-fitnesse-plugin to do a mvn install passing the
acceptance tests
-business analysts:
-run Fitnesse locally against a proper version tag from the VCS
(usually HEAD) and commit new pages if necessary
-use a deployment server with the latest version (SNAPSHOT or
production release) to "play" with the latest soft. But nothing written
here is ever committed to the VCS
-continuous integration server:
-use maven-fitnesse-plugin to run the acceptance tests against
the last version
-updates the deployment server with the latest ok-release
The important point is that there can be a shared Fitnesse server but
only as a sandbox environment to play with the latest release. If
business analysts need to commit pages, they have to test them first on
their private Fitnesse server.
The overall process that I would use is:
-BA+dev: take a story
-BA: create (or update) a Fitnesse page for it
-BA: commit it (don't integrate it yet to the executed acceptance tests)
-Dev: code the fixtures, test the page, commit (add the page to the
acceptance test suite)
-CI env: integrate and deploy to a shared Fitnesse server
-BA: re-run the acceptance tests on the shared server, modify tables to
have a look at other testing possibilities
-BA: optionnaly rework the pages locally and commit them
The drawbacks I see with this approach are:
-you have to have Fitnesse installed on each BA/dev computer
-they need to be "VCS-aware"
-they may need to be "CI-aware" enough to know how to include/exclude an
acceptance test from the suite
-there is no real "wiki community" around the pages
The advantages are:
-you don't have to have a shared Fitnesse server always up (so the
process is more robust, developers can still work if the server is down)
-you can always run the acceptance tests against any release
-the acceptance tests may execute faster (no need to retrieve the pages
through http)
-if BA are really contributing pages, they have to be aware of
versionning, so you control what's in your releases
-you can automate the production of an always coherent context.txt file
from the pom.xml which is in the same project directory. Nobody ever has
to worry about it
-you can debug the fixtures
After all this lengthy description, I would be really interested to know
more about how you are actually working, and who's committing the pages.
Because this BA/Dev interaction to write and maintain Fitnesse pages is
not of the easiest ones!
In your scenario, what I don't understand is how can you run the
acceptance tests against any revision. If the pages come from the
Fitnesse server, they always have a fixed revision tag, don't they?
Eric.
PS: sorry for maven users if this thread is beginning to look like a lot
like a fitnesse-users thread!
-----Original Message-----
From: pkernevez [mailto:[EMAIL PROTECTED]
Sent: Monday, March 05, 2007 6:42 AM
To: 'Maven Users List'
Subject: RE: Using the POM classpath for integration testing
Hi Eric,
I our approach there is always a centralized FitNesse server running.
This server is available for all project people, including non
developers.
Our two main pains in this case is
* to test local development (for a member of the team), without sharing
'non finished code'
* to haven't to upload all of our jars to the server (we have about 10
develpers working with a small WAN connection)
The plugin allows us to:
* download the content of the page instead of upload the jars
* have an insolated workspace for each developers (like for the unit
test
developpement)
* keep an unique Test Repository without allowing the windows fill
sharing (or samba) of the internal FitNesse repository.
In our approach you must have a local (or share folder) FitNesse
repository.
Your can use the Jdk Options of the plugin to start the Jvm with debug
options.
In your approach it seems to be a 'one developer' team or manual
synchronization of the FitNesse repository.
In return, what do you think of this approach ?
Philippe
-----Original Message-----
From: Eric Torreborre [mailto:[EMAIL PROTECTED]
Sent: vendredi 2 mars 2007 02:27
To: Maven Users List
Subject: RE: Using the POM classpath for integration testing
Philippe,
By the way,
I had a different approach for executing the Fitnesse tests. I wrote a
FitnessePageRunner class based on the FolderRunner class in the
fitlibrary.
This way, I don't have to launch a web server to do the job.
The FitnessePageRunner:
-converts content.txt files to html pages using Fitnesse classes -runs
the FolderRunner class -analyzes the indexReport.html page to get the
results
fitnesse-runner is a separate project so I can reuse this class to debug
my application if necessary.
What do you think of this approach?
Eric.
-----Original Message-----
From: Philippe Kernevez [mailto:[EMAIL PROTECTED]
Sent: Friday, March 02, 2007 2:36 AM
To: 'Maven Users List'
Subject: RE: Using the POM classpath for integration testing
Hi Eric,
Do you speak about the fitnesse-maven-plugin ? I suppose that's the
case.
The plugin doesn't use the POM dependencies because they are supposed to
be specified in the Fitnesse page.
The plugin provides a solution to change the server classpath (with
string substitution), this allows to have an unix fitnesse server and to
run the tests on a windows plateform.
I didn't write any documentation yet :-( But, this is my next task.
You may yet find an example with this sample:
https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/fitnesse-maven-plu
gin/
src/it/minimalist/pom.xml
The <classPathSubstitutions> tag allows configuring the plugin for this
use.
You can also add dependencies to your plugin (like Fitnesse), they will
be add to Fitnesse dependencies. In your case, you will have to define
twice your dependency, and it wont be nice.
We could and a tag to know if we want to add the current project
dependencies to FitNesse.
Does it answer to your question?
Philippe Kernevez
(Did we meet in Paris in SITI project ?)
-----Original Message-----
From: Eric Torreborre [mailto:[EMAIL PROTECTED]
Sent: jeudi 1 mars 2007 07:46
To: users@maven.apache.org
Subject: Using the POM classpath for integration testing
Hi,
I have written a simple maven plugin that runs Fitnesse pages during the
integration-test phase.
However, it looks like this plugin, when executed, does not find the
classes that should be provided by the POM (along with dependencies).
Is there is configuration that should be done, in order to make the
plugin aware of the POM classes?
I am certainly missing something very simple, I just don't know what!
Thanks,
Eric.
Eric TORREBORRE
Senior Technical Analyst
Professional Services Asia-Pacific
.................................................
C A L Y P S O
Level 15, JT Building.
2-2-1 Toranomon, Minato-ku,
Tokyo 105-0001
OFFICE +81-(0)3-5114-8262
FAX +81-(0)3-5114-8263
.................................................
www.calypso.com
This electronic-mail might contain confidential information intended
only for the use by the entity named. If the reader of this message is
not the intended recipient, the reader is hereby notified that any
dissemination, distribution or copying is strictly prohibited.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
