Unit testing a database-driven WAMP server

#1

I’m developing a database-driven WAMP server and need to unit test it.

The simplest way to do this would be to create a simple WAMP client and use Python’s built-in unit testing to create some tests. The problem with this is that Autobahn’s WAMP client is asynchronous, which means one test might be running while another test is only halfway done, so I would never know the current state of the database.

I’m looking into Twisted’s Trial, which seems promising.

However, before I dive too deep into this, I’m wondering if any of you more experienced Autobahn developers have some insight and/or sample code to share regarding this.

0 Likes

#2

I'm developing a database-driven WAMP server and need to unit test it.

Some ideas. If you want to test the complete system:

Unit test runs:
- issue RPC
- server side implementation of RPC endpoint does it's stuff and modifies the database
- RPC result comes back

What the unit test now would need to check:
- RPC result
- database state

The unit test would need a WAMP connection to issue the RPC, and an "out-of-band" direct database connection to check the DB state after call return. (In principle, you could implement a generic "runSQL()" RPC endpoint, and do the checking over the same WAMP connection).

It becomes more complex when PubSub gets into the game. Do your server procs dispatch events? Do clients publish events on their own?

The simplest way to do this would be to create a simple WAMP client and
use Python's built-in unit testing to create some tests. The problem
with this is that Autobahn's WAMP client is asynchronous, which means
one test might be running while another test is only halfway done, so I
would never know the current state of the database.

You can sequence / serialize the steps. If you wanna avoid manual callback/errback chaining, you can use inlineCallbacks .. e.g.

https://github.com/tavendo/AutobahnPython/blob/master/examples/wamp/rpc/simple/example2/client_icb.py

I'm looking into Twisted's Trial, which seems promising.

However, before I dive too deep into this, I'm wondering if any of you
more experienced Autobahn developers have some insight and/or sample
code to share regarding this.

test "framework" (there isn't sooo much machinery in there). But how far you are willing to take testing: see comment at the top in reply to your first sentance ..

/Tobias

···

Am 19.06.2013 23:37, schrieb Theron Luhn:
From my point of view, the crucial first question is not the specific

--
You received this message because you are subscribed to the Google
Groups "Autobahn" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to autobahnws+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

0 Likes

#3

Thanks, that was some very helpful feedback.

I’ve rolled my own simple testing script, using quite a lot of inlineCallbacks. (Very useful function/decoration to know about)

···

— Theron

On Wed, Jun 19, 2013 at 3:22 PM, Tobias Oberstein tobias.o...@gmail.com wrote:

Am 19.06.2013 23:37, schrieb Theron Luhn:

I’m developing a database-driven WAMP server and need to unit test it.

Some ideas. If you want to test the complete system:

Unit test runs:

  • issue RPC

  • server side implementation of RPC endpoint does it’s stuff and modifies the database

  • RPC result comes back

What the unit test now would need to check:

  • RPC result

  • database state

The unit test would need a WAMP connection to issue the RPC, and an “out-of-band” direct database connection to check the DB state after call return. (In principle, you could implement a generic “runSQL()” RPC endpoint, and do the checking over the same WAMP connection).

It becomes more complex when PubSub gets into the game. Do your server procs dispatch events? Do clients publish events on their own?

The simplest way to do this would be to create a simple WAMP client and

use Python’s built-in unit testing to create some tests. The problem

with this is that Autobahn’s WAMP client is asynchronous, which means

one test might be running while another test is only halfway done, so I

would never know the current state of the database.

You can sequence / serialize the steps. If you wanna avoid manual callback/errback chaining, you can use inlineCallbacks … e.g.

https://github.com/tavendo/AutobahnPython/blob/master/examples/wamp/rpc/simple/example2/client_icb.py

I’m looking into Twisted’s Trial, which seems promising.

However, before I dive too deep into this, I’m wondering if any of you

more experienced Autobahn developers have some insight and/or sample

code to share regarding this.

You received this message because you are subscribed to the Google

Groups “Autobahn” group.

To unsubscribe from this group and stop receiving emails from it, send

an email to autobahnws+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

From my point of view, the crucial first question is not the specific test “framework” (there isn’t sooo much machinery in there). But how far you are willing to take testing: see comment at the top in reply to your first sentance …

/Tobias

0 Likes