To get your questions answered, please ask on the mailing list. Do not open an issue.
If you are at all unsure whether it's a bug in Capybara or a problem with your code, post on the mailing list instead. If it turns out that it is a bug, we can always open an issue later.
If you are sure that it's a bug in Capybara, open a new issue and try to answer the following questions:
- What did you do?
- What did you expect to happen?
- What happened instead?
Please also post code to replicate the bug. Ideally a failing test would be perfect, but even a simple script demonstrating the error would suffice. You could use this template as a starting point. Please don't send us an entire application, unless the bug is in the interaction between Capybara and a particular framework.
Make sure to specify which version of Capybara you are using.
Feature requests are great, but they usually end up lying around the issue tracker indefinitely. Sending a pull request is a much better way of getting a particular feature into Capybara.
-
Add tests! Your patch won't be accepted if it doesn't have tests.
To run a single test or scenario in development use:focus_metadata, e.g.:
it 'should simulate multiple held down modifier keys', :focus_ do -
Document any change in behaviour. Make sure the README and any other relevant documentation are kept up-to-date.
-
Consider our release cycle. We try to follow semver. Randomly breaking public APIs is not an option.
-
Create topic branches. Don't ask us to pull from your master branch.
-
One pull request per feature. If you want to do more than one thing, send multiple pull requests.
-
Send coherent history. Make sure each individual commit in your pull request is meaningful. If you had to make multiple intermediate commits while developing, please squash them before sending them to us.