maccman / juggernaut

[DEPRECATED] Realtime server push with node.js, WebSockets and Comet
http://alexmaccaw.co.uk
MIT License
1.63k stars 188 forks source link

Testing with Capybara #117

Open kevzettler opened 12 years ago

kevzettler commented 12 years ago

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?

felipecsl commented 12 years ago

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...