Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @eileencodes (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

Thanks for submitting this @palkan - this looks really great! I think asserting that data is being sent is the main thing that should be provided as a test helper (as you have implemented). Not sure what else we want to allow users to test... cc @dhh

TestHelper tests added.

👍 Thank you for you work on this!

Rebase with the current master (due to Cable configuration changes).
Anything else?

r? @matthewd

@palkan Would you be willing to rebase this, and resolve the remaining conflicts? Getting good Action Cable testing infrastructure setup for 5.0 (when Action Cable officially launches) is very important :)

@palkan unfortunately no, the betas are our feature freeze point.

Additionally, I'm going to have to bow out of reviewing these PRs I'm too exhausted at the moment to give this the attention it needs. Let's revisit once 5.2 is completely out the door.

Your dedication to this is admirable and appreciated 👏

Hi, @kaspth! Maybe it's time to re-visit and prepare for 5.2?

Hey! Unfortunately I'm already booked up for 5.2 with a GSoC project and improving things I've directly contributed to 😊

This is a highly important issue. Is anyone else able to push this forward? This is a pretty big part of an application to be untestable.

Agreed. Need this for testing too 👍

Extracted into a separate gem – https://github.com/palkan/action-cable-testing.

@dhh @kaspth I'm not closing this one and #27191, 'cause I hope to get them reviewed+merged one day.

@palkan Great work. Thanks.

Sounds good. Let's keep it in the gem for now ✌️

@kaspth @dhh @rafaelfranca this PR was whipped together in January of 16 and it has been in a nearly 'ready-to-roll' state it seems since Q2 of that year.

Going back and reading through the work that @palkan has put into this there are nine separate instances where requests were made by members of the team that were then immediately implemented without argument or complaint.

It was only after the better part of two years of this being open that he then put this into a gem.

As someone who is passionate about open source contributions and the community, tell me what I can do to help get this PR on to some sort of timeline. Can we give it a flag or label to make it a priority for the 5.3 milestone queue? 😃

Very good points, @Schwad!

I've already tried to find the answers. With no luck.

I would dare to say that Action Cable has no maintainers.

Maybe, "maintainer" is not the right word, 'cause, hopefully, we still have deps updates, small bug fixes and docs updates–some kind of maintenance. But we don't have any new functionality (even such crucial as testing and a lot more, see PRs and issues).

I had to extract two PRs into a gem. What should I do next time I want to improve Action Cable, propose a PR or write yet another gem? I favor the latter one now.

P.S. OSS that stops evolution gradually dies (Matz).

Maybe the gem will have helped with this: have people actually used this in real applications and found it useful? As @dhh has noted, it's solving a problem Basecamp isn't experiencing.

Does anyone have any representative real-world examples of how their tests look when using it?

Anyway, this seems to be a far less intimidating pile of code than it was last time I saw it. I'll try to have a look -- though the gem seemed like a perfectly fine idea to me.

But we don't have any new [Action Cable] functionality

Yep. It's doing its job, and people are spending their limited volunteer time elsewhere. Sorry 🤷🏻‍♂️

Yep. It's doing its job, and people are spending their limited volunteer time elsewhere. Sorry

Not @palkan. So dont feel sorry. Just feel sorry its not been merged into Rails. :)

Thank you so much for being willing to have a look @matthewd :) If there's anything I can do to help on this please let me know.

First of all, thank you, @matthewd!

Does anyone have any representative real-world examples of how their tests look when using it?

A few examples from the wild: one, and two, and three.

There are several reasons to write unit/functional cable tests:

• Access control (who has access to the channel? who can perform action and with what arguments? who can connect to the server?)–similar to controller tests
• Frontend-less applications–no other way to test channels, because no system tests at all

So, system tests (the official testing technique for cable) don't solve all the problems. And also, due to the well-known reasons (slow, hard to maintain, etc.), not everyone writes system tests.

I'll try to have a look -- though the gem seemed like a perfectly fine idea to me.

I agree–having this functionality in a separate gem makes sense. It's much more easier to react on bugs/feature requests and so on. And as long as Action Cable itself is not evolving, there should not be any compatibility issues.

I'd like to propose adding the information about the gem to the guides and, maybe, even include it to the default Gemfile. @matthewd WDYT?

it's solving a problem Basecamp isn't experiencing.

Looks like Basecamp is the only Rails application. Oh, there are also Shopify and Github)

Also, "not experiencing" != "doesn't exist and impossible".

It's doing its job

Unfortunately, IMO it's not doing it well. It could be much better. I've already mentioned some problems here (e.g. #26999), I'm speaking about Action Cable and its problems from time to time (see here, for example) and I have a lot of ideas on how to improve it but... "It's doing its job". I've heard this before.

Nevertheless, I'm still here and willing to help.

And it's Aug 2018 now.

We're using api-only-mode and actioncable to build a pure websocket server, so system tests are out of the picture, and now we're facing some untestable features.

Maybe it's time to revisit the issue?

I'd like to see this get merged for Rails 6.0. Just read through the whole thing, and it seems like the only slight nit left is adding a base class for cable tests, like we have for Action Job, like:

module ActionCable
  class TestCase < ActiveSupport::TestCase
    include ActionCable::TestHelper

    ActiveSupport.run_load_hooks(:active_job_test_case, self)
  end
end

Do you have any other objections, @kaspth?

Ah, I see that #27191 has the base class. That PR has just a few outstanding comments on it. @palkan if you're not burned out over how long this has dragged on, would you mind taking a look? I think we're almost at the finish line here. For realz 😄

And thanks again for your diligent and persistent work on this.

@dhh I'd be glad to finish this feature and finally get it merged)

I'd like to start a new PR for that, 'cause since the action-cable-testing gem has been published, I've made a bunch of fixes and a few more features, so the existing PRs are out of sync.

So, that's gonna be a huge PR – what is the best way to do that from the reviewers point of view? One parent PR and a separate PR for each smaller feature (there gonna 3-4 of them, I think)? Or a single PR with multiple commits reflecting different features? WDYT @matthewd @kaspth

Closed in favour of #33659