Comments (6)
Just to be clear, by anycable i rather mean anycable-rails as that is where these compatibility checks live.
On second thought maybe this (anycable-rails) is the best place to add the conditions, e.g. something like:
unless diff.empty? || (::Rails.env.test? && diff == ['@_streams'])
Obviously this has the extra burden of keeping it up to date with whatever action-cable-testing (or others) will introduce, but i feel anycable-rails already knows about rails, so it's the right place (given this gem is going to be merged into rails proper it will be somewhat part of the api). If you agree with that approach i am happy to create a PR.
from action-cable-testing.
Thanks for the report!
anycable-rails already knows about rails, so it's the right place
Yep, that should be handled by anycable-rails
.
One of the options could be is to add a whitelist of instance variables (and add @_streams
by default if ActionCable::Channel::TestCase
is loaded).
from action-cable-testing.
yes good point, if you agree i can create a PR sometimes tomorrow on anycable-rails
. do you prefer creating an issue on anycable-rails
also?
from action-cable-testing.
if you agree i can create a PR sometimes tomorrow on anycable-rails
Sounds good!
do you prefer creating an issue on anycable-rails also?
No, no need.
from action-cable-testing.
Trying to understand what is the best way to check if the testing part is applied, i am not sure if i understood you correctly, initially i thought we could go with something like defined? ActionCable::Channel::TestCase
(and have an ALLOWED_INSTANCE_VARIABLES
in Compatibility
), but i've realised it does not ensure connection/channel stubbing (as we don't know in Channel::Base
- where the Compatibility
patching is - if we are "running inside" such a test case or not).
I could test for self.singleton_class.include?(ActionCable::Channel::ChannelStub)
, but that would run on every invocation.
If the action-cable-testing
will be merged into rails the first test (checking defined?
) will always be true (i think), so not sure if it is meaningful. Allowing @_streams
unconditionally does introduce an edge-case where people could use that instance variable name ("accidentally") for other purposes (it would lead to problems/failures in test results, but wouldn't raise an error while testing or development).
That is why i think maybe we should try to exclude @_streams
only when we know for sure it is defined by the stubbing (so it would still not raise error while testing, but would raise in development - for when @_streams
is used explicitly by the developer).
from action-cable-testing.
Maybe using a different instance variable name like @_stubbed_streams
would lower the name clash risk so that it can be used unconditionally (and even documented in testing guide so users do not accidentally use it).
Edit: another possibility is if we add some extra method to ChannelStub
like stubbed_channel?
that we can test for in Compatibility
(it would be on every invocation like with singleton_class
, or it could be a class method).
from action-cable-testing.
Related Issues (20)
- 'assert_broadcast_on' is misspelled in README.md and minitest.md HOT 1
- NotImplementedError on disconnect HOT 4
- docs about compatibility/how-to-migrate HOT 4
- multiple connections testing HOT 1
- Rails 6: undefined method `stub_connection' HOT 2
- Readme example issue HOT 2
- Strange behaviour of expect(subscription).to be_rejected HOT 5
- Any ideas about using this gem with `perform_later` method? HOT 2
- params don't seem to be parsed out of connection requests HOT 1
- Test connection with Devise session HOT 2
- Connection is not being closed after test HOT 1
- action-cable-testing does not work with rspec-rails 4.0 and rails 5 HOT 5
- Add ability to match multiple broadcasts HOT 2
- undefined local variable or method `streams' HOT 5
- Does anyone has the same error? HOT 2
- Rails 6.1 support (stop_stream_from) HOT 1
- undefined method `assert_nothing_raised' in gems/actioncable-6.1.1/lib/action_cable/test_helper.rb:48:in `assert_broadcasts' (Rails 6.1, Rspec 4.0.2) HOT 5
- have_broadcasted_to does not seem to work in Rails 5.2 HOT 8
- Testing "transmit" HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from action-cable-testing.