Re: Transactional test assertions timing issue
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() + 1;
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
Re: Transactional test assertions timing issue
Hi Yeah you would need to add a little delay to give time for the TX to commit. As when notify builder matches there is still a little work going on in the consumer still, eg (from activemq). Ideally if the TX manager has some listener api you can hook into, then you can check after it has committed the TX. 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 -- Claus Ibsen - www.camelone.org: The open source integration conference. Red Hat, Inc. FuseSource is now part of Red Hat Email: cib...@redhat.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
Transactional test assertions timing issue
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
