Channels: Add a ChannelLiveServerTestCase (similar to LiveServerTestCase)

[bittner]

At the moment, for testing an application using channels we have two dedicated test case classes:

• ChannelTestCase
• TransactionChannelTestCase

For testing Django live applications (through the whole stack) Django provides two additional test case classes, which come in handy especially in BDD (usually in combination with something like Selenium):

• LiveServerTestCase
• StaticLiveServerTestCase

ChannelLiveServerTestCase

As for channels we have a completely different execution profile (we need interface servers and worker servers), yet still the same need for testing features, it would be helpful to have a similar test case class for testing across the Channels stack, e.g.

• ChannelLiveServerTestCase

Why In Channels?

For obvious reasons (testing) it makes sense that this is integrated in Channels rather than a third-party package.

Examples Of Usage

We have discussed this in https://github.com/behave/behave-django/issues/16#issuecomment-274127381.

Setting up a test setup for use with Splinter or Selenium is pretty laborious, as demonstrated in the same issue (comment above). A ChannelLiveServerTestCase would make that much easier, and the Django testing picture more complete.

[andrewgodwin]

I agree it would be useful, but this falls outside my knowledge and experience range - I do not want to spend time getting tests working with WebSockets from browsers, they're finicky at the best of times. We can leave this open, though, as someone else may be interested.

[bittner]

Thank you, @andrewgodwin, for agreeing!

It's not even about browsers at all. LiveServerTestCase is spinning up a runserver in the setupClass method of a TransactionTestCase.

For Channels this should be merely a copy of the LiveServerTestCase code, spinning up a Daphne instance and worker servers instead. Though I'm not sure whether ChannelLiveServerTestCase shouldn't really be a subclass of LiveServerTestCase (or StaticLiveServerTestCase), which _also_ spins up Daphne and worker servers (given the use case that Ian Sparks describes).

Actually, there's one particular paragraph in the "Getting Started" chapter of the docs that makes me hope it's particularly straightforward to implement:

(Under the hood, runserver is now running Daphne in one thread and a worker with autoreload in another - it’s basically a miniature version of a deployment, but all in one process)

Let's see if someone from the behave community is ready to place a PR. Maybe you can give some helpful hints.

[proofit404]

The first version of integration test suite in asgi_rabbitmq contains very similar test case. It runs with in memory layer. I can try to adapt it.

[andrewgodwin]

@bittner If you want to have a look at the work being done in #497 and leave comments, that would be great.

[proofit404]

We can close this one.

[andrewgodwin]

Yes, we can!