I think it sounds reasonable. A couple of things I would add:
1. We may want to look at making this into a generic deploy harness
(in addition to some type of "native" deployment on host platforms,
e.g. a J2EE server or OSGi container)
2. I think we also need to clearly establish best practices around
testing. For example, as you mentioned below, this harness should be
used for integration testing and specifically to ensure componentry
works correctly when deployed to the runtime. Its purpose is not to
unit test application code. Unit testing of application code should
be done without any Tuscany jars on the classpath. To help promote
this, we should follow these guidelines in our sample applications.
Jim
On Aug 3, 2006, at 9:18 AM, Jeremy Boynes wrote:
We've talked a lot recently about issues booting the server inside
the build environment in order to be able to test application code.
I think one way we might be able to solve this is through a client-
side test harness that can be integrated into Maven and Ant.
An essential observation here is that users will typically be
exposing services in the server rather than applications. Therefore
we should have a test harness capable of interacting with those
services rather than use application testing harnesses like HTMLUnit.
We can do this with an extensible SCA test harness that allows
people to easily access the services on the server. This can be an
SCA "client" environment containing just bindings, combined with
some utility functions to deploy applications to the server.
In a Maven environment, it would work like this (based on Maven
build phases):
compile: compile the application code
test: run unit tests on the application code inside Maven - no
SCA functions available
package: package up the application composite
pre-integration-test:
deploy the package to a Tuscany server (potentially
booting the remote server)
boot the test-harness Tuscany client with the appropriate
bindings
integration-test:
run integration/functional test against the exposed services
the user's test code would access the server using SCA
References
post-integration-test:
shutdown the test-harness client
undeploy the application (and possibly stop the remote
server)
We would do a similar thing for Ant with different task definitions
for the various stages.
Seem reasonable?
--
Jeremy
---------------------------------------------------------------------
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]