Community
Participate
Working Groups
When unit testing code with JMS you'll typically want to avoid the overhead of running separate proceses; plus you'll want to increase startup time as fast as possible as you tend to run unit tests often and want immediate feedback. Also persistence can often cause problems - as previous test case results can adversely affect future test case runs - so you often need to purge queues on startup. [0] [0] http://activemq.apache.org/how-to-unit-test-jms-code.html
(In reply to comment #0) > When unit testing code with JMS you'll typically want to avoid the overhead of > running separate proceses; plus you'll want to increase startup time as fast as > possible as you tend to run unit tests often and want immediate feedback. Also > persistence can often cause problems - as previous test case results can > adversely affect future test case runs - so you often need to purge queues on > startup. [0] > > [0] http://activemq.apache.org/how-to-unit-test-jms-code.html Two points: 1) Having everything in one process (including broker) may be easier, but it also results in less useful testing...since the timing and graceful handling of failure in inter-process communication is frequently the 'hard part' of testing remote services...and the timing and failure of things is affected significantly by not having separate processes. 2) We don't currently have an embedded broker container. It would probably be fairly simple to create given the instructions on [1], but we don't have it. Further, it would/will likely require a number of third party libs (that activemq depends upon)...and should probably be therefore introduced via a new bundle so as not burden the org.eclipse.ecf.provider.jms.activemq bundle with more/larger code.
(In reply to comment #1) > 1) Having everything in one process (including broker) may be easier, but it > also results in less useful testing...since the timing and graceful handling of > failure in inter-process communication is frequently the 'hard part' of testing > remote services...and the timing and failure of things is affected > significantly by not having separate processes. In the long run I totally agree with you. Eventually we definitely want to test ECF providers under real world conditions. But as long as we don't have a full featured test bed (e.g. simulating network outages), running tests in separate VMs IMO causes more problems/work than what it buys us. I see the current tests more like API tests/verification. > 2) We don't currently have an embedded broker container. It would probably be > fairly simple to create given the instructions on [1], but we don't have it. > Further, it would/will likely require a number of third party libs (that > activemq depends upon)...and should probably be therefore introduced via a new > bundle so as not burden the org.eclipse.ecf.provider.jms.activemq bundle with > more/larger code. From my local tests it looks like we just have to change org.eclipse.ecf.tests.provider.jms.activemq.ActiveMQ.TARGET_NAME to "vm://localhost/?broker.persistent=false". No extra jars no nothing. Anyway, for the moment I simply switched to a system property and overwrite the standalone URL with the embedded one in the new .launch. Better than no tests at all. :)
Created attachment 175890 [details] mylyn/context/zip
Added jSLP discovery container to build deps
Created attachment 175999 [details] mylyn/context/zip
