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]

Reply via email to