Build times [was Re: [IMPASSIONED PLEA] Naming and structuring test materials]

[Dan Diephouse]

+1 to that as well. Also, re: build times - We could make some of the tests not start up two instances of Spring/CXF. What exactly are we trying to test for when we do that? Client/Server should be completely isolated from each other even without that. With the exception of WS-RM/Addr I don't really see this as adding a lot of benefit. Maybe if we could establish what types of errors we're testing for here and then create a smaller set of test cases around that as opposed to making ever system test start two instances. Benson Margulies wrote: I'm all in favor of #1. In my perhaps unlucky experience, I keep running into 'standard' impls that are to quirky to reuse. On Mon, 2007-12-17 at 09:49 -0500, Daniel Kulp wrote: Fred, On Friday 14 December 2007, Fred Dushin wrote: I understand why the testutils stuff is there, but I don't like it. The idea is to shorten build times, by putting a common set of functionality in a JAR, and re-use to your heart's content. The idea isn't just to shorten the build time, although that's a great benifit. There are two main reasons: 1) Provide a set of standard "Impls" that could be reused by tests so you don't need to write a bunch of new Impls for everything. For example, simple, jaxws, js, etc... all need some simple server side impls to do various testing. I don't believe in copying the same code all over the place. That kind of destroys the whole idea of code reuse. 2) Related to (1) is the problems that copying the code all over the place has on IDE's, specifically eclipse. When building with maven, it doesn't put test classes from one project onto the paths of other projects. However, the way eclipse:eclipse sets up the eclipse projects, it does in eclipse. Thus, you end up with two classes with the same names on the classpath and if they get modified, you get random failures and such. Thus, when you copy, you would also need to make sure to change all the namespaces, change the package names, etc... Thus, creating even more work for your self. You also have that issue with the /wsdl directory. If there is a /wsdl/hello_world.wsdl in testutils, and you try to have a /wsdl/hello_world.wsdl in your own set of tests, you may or may not get the correct one when you run your tests. (which is why I went through an renamed a bunch of /wsdl dir to /wsdl_MODULE for /wsdl dirs outside of testutils). My problem with that is re-use doesn't always work, so you get what you observe -- lots of test-specific functionality in testutils. (Look at hello_world_secure.wsdl, for an example). Well, if it's specific to just the system tests, put it in the system tests. Don't put it in testutils. The point of testutils was to be a place for SHARED stuff. If it's not shared, don't put it there. Or, import the stuff from testutils. (The catalog stuff should all be working now. You can import via testutils/hello_world.wsdl or similar). -- Dan Diephouse MuleSource http://mulesource.com | http://netzooid.com/blog