Testing ApplicationSession components

#1

Hello,

I’d like to know which is the best way to unit test ApplicationSession functions (publications, subscriptions, calls) without running a router (mocking the router)?

Is there any example or guide?

Regards

Roberto

0 Likes

#2

Hello Roberto,

I do not know of any examples or guides for this.

Maybe somebody else in the community has done work on this before and would like to share? It’s a good question.

Regards,

Alex

···

Am Dienstag, 15. September 2015 10:14:29 UTC+2 schrieb Roberto Barreda:

Hello,

I’d like to know which is the best way to unit test ApplicationSession functions (publications, subscriptions, calls) without running a router (mocking the router)?

Is there any example or guide?

Regards

Roberto

0 Likes

#3

Hi Roberto,

Hello,

I’d like to know which is the best way to unit test ApplicationSession functions (publications, subscriptions, calls) without running a router (mocking the router)?

Is there any example or guide?

I’ve been thinking a bit about this myself.

At my work, we have so far not written any unit tests for the actual ApplicationSession classes that we have. In our case, most of these classes are quite simple, and delegate to other classes (custom Twisted protocol classes or other helper classes). What we’ve done is write unit tests for the custom protocol classes and helpers, but none for the ApplicationSession classes (so far). In our unit tests for the custom protocol classes we make use of Twisted’s Trial tool to write “asynchronous” unit tests, and also the mock package to do mocking.

To do what (I think) you’re asking about, that is to write unit tests for the actual ApplicationSession class, I would use the mock package and (very roughly):

To test e.g. onJoin / “initialization”:

  1. Construct an instance of the ApplicationSession under test.
  2. Mock ApplicationSession.register/.call/.subscribe et.c. (and other methods) as appropriate.
  3. Call onJoin.
  4. Assert that calls to the mocked methods were made as expected.

Then, to test e.g. RPC endpoint methods and subscription handlers, I would similarly:

  1. Construct and instance of the ApplicationSession under test.
  2. Mock whatever collaborators the method under test is using.
  3. Call the method under test.
  4. Assert that calls to the collaborators were made as expected.
  5. Assert that the method gave the right result or failed as expected.

For testing methods that return Deferred, the successResultOf, assertFailure and other helpers from Trial is quite handy.

The above are just some very rough templates, but shows how I would go about it. The key thing is that I would mock the .call, .subscribe et.c. methods that ApplicationSession provides using the mock package, to avoid the need for a running router.

Cheers,
Elvis

···

On Tuesday, September 15, 2015 at 10:14:29 AM UTC+2, Roberto Barreda wrote:

Regards

Roberto

0 Likes