There are a few pieces needed for a conformance test for Tuscany Java SCA.
1) The OASIS test framework, including the RuntimeBridge, TestConfiguration,
BaseJAXWSTestCase and TestInvocation WS.
2) The Tuscany implementation of RuntimeBridge (client.TuscanyRuntimeBridge)
3) General resources such as the WSDL/XSD and composite files (under
src/main/resources/General)
4) General Java resources (under src/main/resources/General_Java)
5) Generate Java classes (under src/main/resources/General_Java)
6) Test-specific resources such as META-INF/sca-contribution.xml and the
composite files (under src/main/resources/<Test>)
7) Test-specific java classes (optional, under src/main/resources/<Test>)
8) A client test case for the specific test such as client.ASM_4004_TestCase
I assume 1-5 is common to all Java related tests. My understanding is that a
typical test will involve:
a) 3 is packaged as the "General" contribution and 4-5 is packaged as the
"General-Java" contribution
b) 6-7 is packaged as the "Test" contribution
c) The Tuscany runtime will launch the test application using the SCA
contributions from b and c.
d) The client test case (8) uses 1,2 to launch the JAX-WS client to run the
test and verify the results
So from the code structure perspectives, it would be good see the following
projects in my IDE:
1) The test framework
2) The tuscany runtime bridge (depends on 1, or can be part of 1)
3) The General contribution
4) The General Java contribution (with SCAimports to 3)
5) The Test contribution (resources and java code)
6) The Test client for the given test (depends on 1).
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <[email protected]>
Sent: Wednesday, July 29, 2009 10:09 AM
To: <[email protected]>
Subject: Re: running the otests
I think if Mike were open to reviewing the OASIS test structure we
should go further than this, The ant file in Tuscany doesn't
reorganize the code after it's checked out it's simply a tool to
generate poms that do the reorganization.It helps us trial what an
appropriate structure might be.
The main problem I found with trying to deal with the "all tests in a
single module" approach was getting it to work in Eclipse in a way
that was automatically generatable from the maven build. This becomes
particularly problematic if you want the contributions to be presented
as anything other than folders (something that is easy if the
contributions are in separate modules).
Regards
Simon
