Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Testing with Capybara #117

Open
kevzettler opened this issue Jan 13, 2012 · 1 comment
Open

Testing with Capybara #117

kevzettler opened this issue Jan 13, 2012 · 1 comment

Comments

@kevzettler
Copy link

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants