Announcement Announcement Module
No announcement yet.
Testing flows Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Testing flows

    How do you usually test spring flows? For instance I'd like to test a flow that stores file into a directory or sends message via JMS. I don't want to create wire-taps just for the sake of tests in the channels directing to those adaptors, so I'd like to have a way to know what messages those adaptors or channels received.
    Any suggestions? I think it might make sense to have such a back door since it's really needed all the time.

  • #2
    There are several ways to do it.

    A common approach is to use Spring 3.1 profiles.

    In the default profile, have the final channel connected to the outbound adapter.

    In the 'test' profile, make the final channel a queue channel and then receive() the message from it in your test case.

    <beans... >
        <beans profile="default">
            <int:channel id="final"/>
            <int-file:outbound-channel-adapter ... input-channel="final" ... />
        <beans profile="test">
            <int:channel id="final">
    Then in your test case, set system property "" to "test", inject (e.g. @Autowire) the 'final' channel into your test case and use final.receive() to get the message.


    • #3
      Another option is to have your test configuration XML import the "real" XML but then override some channel definitions. It's also common to override other beans with mocks in that test config (e.g. those that integrate with external systems).


      • #4
        Don't you want to come up with adhoc approach here? For instance some brand new ApplicationContext: IntegrationTestApplicationContext that does some 'enhancing' of channels/adaptors. And then some spring-integration module that could do something like: expect(1).withHeaders(..).withBody(..)? For the TestContext you also could come up with your own @IntegrationContexts annotation that does uses this particular type of spring contexts.
        All the listed approaches are pretty heavy-weight meaning that you have to organize your contexts (as well as prod ones) in a particular way. With profiles we might end up having half of channels duplicated, with bean replacement we need to either separate out things that should be replaced into different contexts or create a single 'supreme' test context which will be importing all others (because if we have beans in the sibling contexts, you can't say what bean should be replacing and what bean should be replaced).
        It looks like a good niche to improve in SI.