Agreed. The only way would be to use mock for junit tests, then create some integration tests for all the supported containers. Also, some tests will be very difficult to rewrite without the actual containers. For example servicemix-eip contain some tests that use the JMS and JCA flow (which are smx3 specific atm), and I don't really see how to mock those (wrt transactions and such), or at least, I'm not sure what the benefit is wrt the huge work it would involve.
On Thu, Jun 5, 2008 at 9:35 AM, Lars Heinemann <[EMAIL PROTECTED]> wrote: > Bruce, > > there is one big backdraw on your suggestion. > The quality of the testing is very dependent to the quality of the mock > classes used. After running such tests you can never say that a component > works with either smx3 or smx4 as they were never really tested with the > containers itself. > > Lars > > > > On Thursday 05 June 2008 09:32:14 Bruce Snyder wrote: >> On Thu, Jun 5, 2008 at 1:18 AM, Guillaume Nodet <[EMAIL PROTECTED]> wrote: >> >>> 3). Because the components are going to be separate from any SMX >> >>> version, we will need some strategy for testing the components against >> >>> SMX3 or SMX4 or both in the same build (I am thinking we could use >> >>> profiles). The real question is how to do this now that the components >> >>> will live on their own. Ideas are welcomed... >> >> >> >> I've given this some thought and I've come to the conclusion that we >> >> need to use mocks. This can be done in one of two ways: >> >> >> >> 1) Build out more a feature complete mock framework by moving the >> >> classes in the servicemix-core component's >> >> org.apache.servicemix.tck.mock package to a separate project named >> >> servicemix-mock, OR >> >> >> >> 2) Use EasyMock (http://easymock.org/) to mock all the necessary >> >> behavior provided by an embedded SMX container and anything else >> >> surrounding it. >> >> >> >> In the past I've used both of these approaches for various projects >> >> and each has its own set of advantages and disadvantages. I lean >> >> toward the use of EasyMock because it's more flexible than creating >> >> our own mock objects simply because I've found that mock objects are >> >> constantly being refactored to account for unforeseen items. I'm gonna >> >> start with the EasyMock approach. >> > >> > 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. >> >> Because the unit tests for the components should no longer rely upon >> either smx3 or smx4 containers. They need to be individually testable >> and we shouldn't need to create separate tests for each component for >> smx3 and smx4. Furthermore, starting up/shutting down a container for >> each test just simply takes too long as the number of tests grows. >> >> Bruce > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
