Jim, > Dan, you mentioned on chat that Celtix has a mechanism for doing > integration testing. I raised this question a several times on the > list (we have a lot of duplicate "mock" code". Could you describe > what you guys have done and if you think it is appropriate for us? I > think you are running into some problems related to this as you write > unit tests for the Celtix binding since many of the mock classes and > factories will need to be copied.
There are a few parts to that question: 1) Code re-use in tests - For celtix, we created a "testutils" project that puts a lot of common utilities and such as "src/java/main", not test code. Thus, the other projects that need it just depend on that project with <scope>test</scope>. There isn't any copying of classes and such from one project to a bunch of other projects. 2) The testutils project also contains a bunch of "common" test wsdls. doc/lit, doc/lit wrapped, rpc/lit, JMS endpoints, XML bindings (not soap), a "type test" wsdl (contains about 150 different schema types with "echo" operations for each), etc.... As part of the testutils build WSDL2Java is run on all of them to generate interfaces and types. There are also sample "server implementations" for all of them in the testutils. Thus, if a test needs a server implementation of something, they are already available. (the tools project where java2wsdl lives must be built before the runtime parts which is different than tuscany. How do people that want to test things use generated code in tests currently in tuscany? Is the code just checked in? The only place we allow that is for tests in the tools package itself. All the others are NOT allowed to check in generated code. The code must be generated as part of the build, but mostly we just rely on stuff from testutils.) 3) Celtix supports a "pipe" protocol/url for soap:address. Thus, in a test, you can pop up a server on a "pipe" and hit it with a client. This involves no tcpip traffic, not HTTP port, etc... Thus, testing complete round trips in a single VM is a bit easier and lighter weight. 4) For more complex "integration" tests (we call them system tests, also used in our Axis interop tests), the testutils package also contains utilities for setting up, forking, and controllling background servers. Thus, in our JUnit style tests, in the "setUp" method (or more likely in the suite(..) method), you can just call "startServer(new ServerClass())" type of method to start a background server process. (again, most of the Server classes are also part of the testutils project and available everywhere). 5) Server behavior: the "normal" mechanism for creating/writing/starting a server in Celtix is NOT to deploy a war into tomcat or some other web application. MOST of our users don't use any type of app server or servlet engine or anything for hosting their servers. (Celtix does support it, but it's not the normal case) In celtix, (with the JAX-WS apis's) you can just create a main method with something like: Endpoint.publish(wsdlurl, new ServerImpl()); and Celtix will startup Jetty (if the wsdl is HTTP), or a JMS queue (if JMS, JMS broker does need starting externally first) or whatever else is needed. This also makes testing a LOT easier as you don't need to figure out how to deploy to tomcat, control tomcat, etc... 6) Mock stuff: we use easymock. We don't really have any Mock things hand coded and checked in. We just allow easymock to create them as needed. I hope this helps answer some of the questions. I'd be happy to expand on any of those a bit more if needed. I guess the two things I'd like some sort of solution to are: 1) Utility code re-use (for things like Mock factories and such) 2) Generated code use - currently impossible as the SCA tools are built too late in the cycle. We can currently just use generated SDO code. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED]
