Transactional test assertions timing issue

[Alex Sherwin <al...@gmail.com>]

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

[Christian Müller <ch...@gmail.com>]

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 <al...@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

[Claus Ibsen <cl...@gmail.com>]

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 <al...@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: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen