I guess we could also make a difference between integration tests that use smx embedded, but the real protocol (which is what nrealy all our tests do) or use the packaged JBI component and a start a full container (we have none of these kind right now).
Anyway, I think we are disgressing a bit here. The first goal is to split the components from the smx3 container, not to rewrite all the tests (or enhance them), which is a long running task, but is not really related to the svn organization and the split of the components imho. On Thu, Jun 5, 2008 at 9:53 AM, Gert Vanthienen <[EMAIL PROTECTED]> wrote: > L.S., > > I agree it would be good thing to make a distinction between unit tests and > integration tests. We should probably have both of them: unit tests could > use the mock test framework and for the integration tests, we should keep on > using the containers. > > For the integration tests, wouldn't it be possible to write most of them in > a form that allows to test them on both versions of the container > automatically. Another idea (probably slightly out-of-scope for now)= we > could look into is doing multiple integration tests with a single container > instance. The Maven itests should allow us to: > - start a container in pre-integration-test > - deploy/test/undeploy for a set of integration tests > - stop the container in post-integration-test > > This should reduce the overhead of starting/stopping the container over and > over again, making the tests easier/faster to run -- I know the container is > lightweight thing, but it should still make a difference, no? > > Regards, > > Gert > > Chris Custine wrote: >>> >>> I don't really see why we should not continue using the containers for >>> unit testing. It would be a major work to remove the references to >>> the container, or even to rewrite all the tests using mocks instead of >>> the containers. Furthermore, booting smx3 is very fast and >>> lightweight. >>> >> >> >> I agree with Guillaume here. I definitely want to continue integration >> tests inside the container. I was mainly talking about adding a way to >> test >> against specific versions of the container or maybe even multiple version >> in >> the same build? Currently the components inherit the version of the >> container from the parent pom, and we will have to make this a >> configurable >> property for selecting the container version when running tests. >> >> If anything, a mock strategy could be in addition to the itests, but not >> sure if I would drop integration tests. >> >> >> >>>> >>>> Bruce >>>> -- >>>> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
