If you have to do it by yourself (as we have to do it some time), you could
do it in this way (template is an instance of Springs JDBCTemplate):
private void assertDatabaseCount(int count) throws InterruptedException {
long timeout = System.currentTimeMillis() + 10000;
while (timeout > System.currentTimeMillis() &&
template.queryForInt("SELECT COUNT(*) FROM FOO_TABLE") < count) {
Thread.sleep(200);
}
assertEquals(count, statisticMock.size());
}
Best,
Christian Müller
-----------------
Software Integration Specialist
Apache Camel committer: https://camel.apache.org/team
V.P. Apache Camel: https://www.apache.org/foundation/
Apache Member: https://www.apache.org/foundation/members.html
https://www.linkedin.com/pub/christian-mueller/11/551/642
On Tue, Jun 4, 2013 at 5:31 PM, Alex Sherwin <alex.sher...@gmail.com> wrote:
> When unit (integration) testing a transacted route, such as (pseudo):
>
> <route>
> <from uri="activemq:some queue"/>
> <transacted/>
> <camel:process ref="someBeanProcessor"/>
> </route>
>
> Where "someBeanProcessor" does some DB work and participates in a JTA
> transaction with the JMS message on this route
>
> The problem is, what is a reliable way to apply an assertion on the work
> that "someBeanProcessor" has done in the DB? I've tried both of the
> following:
>
> 1. Add <to: uri="log:some.logger.success?level=DEBUG"/>, get a MockEndpoint
> ref and use an expected message count of 1, and wait on
> mock.assertIsSatisified()
>
> 2. Use a NotifyBuilder on the route and use whenComplete(1), and wait on
> builder.matchesMockWaitTime()
>
> Both have the same result, where my test code is told about the success
> before the JTA transaction has finished comitting, so when the test thread
> performs a SQL select, it is doing so too early since the JTA tx of the
> route hasn't actually completed.
>
> This scenario works OK if the end result is something like <to
> uri="activemq:out queue"/> and I use a MockEndpoint on the JMS output URI,
> which makes sense since it'd be waiting on the TX to commit here; but what
> about routes where this isn't an option?
>
> Do I just need to suck it up and use Thread.sleep(..) on the test thread?
>
> Thanks,
>
> --
> Alexander Sherwin
>
