You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is less of an issue and more of a discussion.
I'm building out some high level javascript integration tests, using rspec2, capybara, and capybara-webkit. I'm now running into an issue where a lot of my scripts expect the Juggernaut connection to be there but are erring out.
Wondering what a best practice is here. Does this need any other consideration besides run juggernaut along side your tests? Can it be mocked/stubbed?
The text was updated successfully, but these errors were encountered:
Hi @kevzettler, I am running into the same scenario right now and here are my findings so far:
For specs, we run redis in a non-default port (9736) so that it does not conflict with development redis.
For Juggernaut, you have 2 concerns: First is you have to start the server after you started redis. Second is it isnt possible yet to override the port that Juggernaut uses to connect to redis, so basically you are restricted to the default one (6379). this pull request adds this ability, but apparently has been sitting there for a while. In my case, my only option would be to change the test redis port to the default one, since there is no way to override that when starting juggernaut (so far). Haven't considered stubbing since we're talking about integration tests.
Hope this helps someone...
This is less of an issue and more of a discussion.
I'm building out some high level javascript integration tests, using rspec2, capybara, and capybara-webkit. I'm now running into an issue where a lot of my scripts expect the Juggernaut connection to be there but are erring out.
Wondering what a best practice is here. Does this need any other consideration besides run juggernaut along side your tests? Can it be mocked/stubbed?
The text was updated successfully, but these errors were encountered: