> If there's no way inside the server then this portion of code > will never be > called and hence you don't need to test it! :-) > > This EJB will usually be called by a Servlet or some MDB > or... So you'll > intercept using the same principle as it is currently done > with Cactus.
Sure, most server services can be called or rather triggered remotely. However, I can see the need for services that has no remote api and is only triggered via timers inside the server. More importantly one could be developing a reusable component with no remote api. The component will later on be invoked by servlets or MDB:s for instance. When developing our component we want to focus on that and write integration tests for it without having to bother about the parts of the system that will be invoking it. These part may not yet exist. I would still argue its a valid integration test since it tests the component running in its container working against a real database. One of the main reasons we are using Cactus today is the ability to run the actual test on the server within the servlet that Cactus provides for us. From within the servlet we can insantiate server components like local session EJB:s and run integration tests on them. It seems to me that it will be much more cumbersome to write these kind of test with the new architecture. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
