Contributing

RSpec is a community-driven project that has benefited from improvements from over 500 contributors. We welcome contributions from everyone. While contributing, please follow the project code of conduct, so that everyone can be included.

If you'd like to help make RSpec better, here are some ways you can contribute:

by running RSpec HEAD to help us catch bugs before new releases
by reporting bugs you encounter
by suggesting new features
by improving RSpec's Feature or API documentation
by improving RSpec's website (source)
by taking part in feature and issue discussions
by adding a failing test for reproducible reported bugs
by reviewing pull requests and suggesting improvements
by writing code (no patch is too small! fix typos or bad whitespace)

If you need help getting started, check out the DEVELOPMENT file for steps that will get you up and running.

Thanks for helping us make RSpec better!

Rspec issues labels definition

`Your first PR` issues

These issues are the ones that we be believe are best suited for new contributors to get started on. They represent a potential meaningful contribution to the project that should not be too hard to pull off.

`Needs reproduction case` issues

These issues are ones that have been labelled by the maintainers that we believe do not currently have enough information to be reproduced the RSpec team. While not directly counted by the GitHub contribution graph, we consider helping us to reproduce the issue with a repro case as an extremely meaningful contribution.

`Has reproduction case` issues

These issues are the ones that have reproduction cases, able to start working on immediately. These are good ones to tackle to help us actively fix bugs.

Maintenance branches

Maintenance branches are how we manage the different supported point releases of RSpec. As such, while they might look like good candidates to merge into main, please do not open pull requests to merge them.

How do the cukes work?

The cucumber features for RSpec rails document how it works, but are also quasi executable tests for the framework. They execute in the context of a pre-setup Rails app.

Before the cucumber specs run, the directory tmp/aruba is cleared
If the example app hasn't already been created, bundle exec rake generate:app generate:stuff is executed.
The example app is copied in to tmp/aruba
Everything in tmp/aruba/spec/* is deleted apart from spec/spec_helper.rb and spec/rails_helper.rb
the cucumber suite executes, creating files in that app and executing them

The best way to debug the app is to run a failing cucumber feature, which will leave the test files intact in tmp/aruba, then you can cd in to that director and run it in the bundle context of the aruba app.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!