+ 1

What is RSpec?

Behaviour Driven Development for Ruby. Making TDD Productive and Fun.
RSpec is a tool in the Testing Frameworks category of a tech stack.
RSpec is an open source tool with 2.6K GitHub stars and 215 GitHub forks. Here鈥檚 a link to RSpec's open source repository on GitHub

Who uses RSpec?

91 companies reportedly use RSpec in their tech stacks, including StackShare, MAK IT, and Youboox.

147 developers on StackShare have stated that they use RSpec.

RSpec Integrations

Why developers like RSpec?

Here鈥檚 a list of reasons why companies and developers use RSpec
Top Reasons
Be the first to leave a pro
Public Decisions about RSpec

Here are some stack decisions, common use cases and reviews by companies and developers who chose RSpec in their tech stack.

I'm working as one of the engineering leads in RunaHR. As our platform is a Saas, we thought It'd be good to have an API (We chose Ruby and Rails for this) and a SPA (built with React and Redux ) connected. We started the SPA with Create React App since It's pretty easy to start.

We use Jest as the testing framework and react-testing-library to test React components. In Rails we make tests using RSpec.

Our main database is PostgreSQL, but we also use MongoDB to store some type of data. We started to use Redis 聽for cache and other time sensitive operations.

We have a couple of extra projects: One is an Employee app built with React Native and the other is an internal back office dashboard built with Next.js for the client and Python in the backend side.

Since we have different frontend apps we have found useful to have Bit to document visual components and utils in JavaScript.

See more
Simon Bettison
Simon Bettison
Managing Director at Bettison.org Limited | 7 upvotes 228.5K views

In 2010 we made the very difficult decision to entirely re-engineer our existing monolithic LAMP application from the ground up in order to address some growing concerns about it's long term viability as a platform.

Full application re-write is almost always never the answer, because of the risks involved. However the situation warranted drastic action as it was clear that the existing product was going to face severe scaling issues. We felt it better address these sooner rather than later and also take the opportunity to improve the international architecture and also to refactor the database in. order that it better matched the changes in core functionality.

PostgreSQL was chosen for its reputation as being solid ACID compliant database backend, it was available as an offering AWS RDS service which reduced the management overhead of us having to configure it ourselves. In order to reduce read load on the primary database we implemented an Elasticsearch layer for fast and scalable search operations. Synchronisation of these indexes was to be achieved through the use of Sidekiq's Redis based background workers on Amazon ElastiCache. Again the AWS solution here looked to be an easy way to keep our involvement in managing this part of the platform at a minimum. Allowing us to focus on our core business.

Rails ls was chosen for its ability to quickly get core functionality up and running, its MVC architecture and also its focus on Test Driven Development using RSpec and Selenium with Travis CI providing continual integration. We also liked Ruby for its terse, clean and elegant syntax. Though YMMV on that one!

Unicorn was chosen for its continual deployment and reputation as a reliable application server, nginx for its reputation as a fast and stable reverse-proxy. We also took advantage of the Amazon CloudFront CDN here to further improve performance by caching static assets globally.

We tried to strike a balance between having control over management and configuration of our core application with the convenience of being able to leverage AWS hosted services for ancillary functions (Amazon SES , Amazon SQS Amazon Route 53 all hosted securely inside Amazon VPC of course!).

Whilst there is some compromise here with potential vendor lock in, the tasks being performed by these ancillary services are no particularly specialised which should mitigate this risk. Furthermore we have already containerised the stack in our development using Docker environment, and looking to how best to bring this into production - potentially using Amazon EC2 Container Service

See more
StackShare Editors
StackShare Editors

In late 2013, the Operations Engineering team at PagerDuty was made up of 4 engineers, and was comprised of generalists, each of whom had one or two areas of depth. Although the Operations Team ran its own on-call, each engineering team at PagerDuty also participated on the pager.

The Operations Engineering Team owned 150+ servers spanning multiple cloud providers, and used Chef to automate their infrastructure across the various cloud providers with a mix of completely custom cookbooks and customized community cookbooks.

Custom cookbooks were managed by Berkshelf, andach custom cookbook contained its own tests based on ChefSpec 3, coupled with Rspec.

Jenkins was used to GitHub for new changes and to handle unit testing of those features.

See more
Jerome Dalbert
Jerome Dalbert
Senior Backend Engineer at StackShare | 6 upvotes 6.4K views
Shared insights

We use RSpec because it is a de-facto Rails industry standard.

minitest was an interesting alternative because it was part of the Ruby standard library, but this is not the case any more. Also, at the time of writing, the real-world-rails collection shows that it is used in only 31 Gemfiles vs 135 Gemfiles for RSpec.

RSpec works reliably well for an overwhelming majority of people who are used to it, so I guess that is why they don't see a need to change.

See more
Jerome Dalbert
Jerome Dalbert
Senior Backend Engineer at StackShare | 5 upvotes 328.9K views

The continuous integration process for our Rails backend app starts by opening a GitHub pull request. This triggers a CircleCI build and some Code Climate checks.

The CircleCI build is a workflow that runs the following jobs:

  • check for security vulnerabilities with Brakeman
  • check code quality with RuboCop
  • run RSpec tests in parallel with the knapsack gem, and output test coverage reports with the simplecov gem
  • upload test coverage to Code Climate

Code Climate checks the following:

  • code quality metrics like code complexity
  • test coverage minimum thresholds

The CircleCI jobs and Code Climate checks above have corresponding GitHub status checks.

Once all the mandatory GitHub checks pass and the code+functionality have been reviewed, developers can merge their pull request into our Git master branch. Code is then ready to deploy!


See more
Joel Davison
Joel Davison
Junior Web Developer at Ngakkan Nyaagu | 1 upvotes 3K views
Shared insights

RSpec is used to run automated tests, mostly for the purpose of integration testing when developing on top of V1 of the API. RSpec

See more

RSpec Alternatives & Comparisons

What are some alternatives to RSpec?
Cucumber is a tool that supports Behaviour-Driven Development (BDD) - a software development process that aims to enhance software quality and reduce maintenance costs.
Capybara helps you test web applications by simulating how a real user would interact with your app. It is agnostic about the driver running your tests and comes with Rack::Test and Selenium support built in. WebKit is supported through an external gem.
It is an open-source testing framework for infrastructure with a human- and machine-readable language for specifying compliance, security and policy requirements.
A framework makes it easy to write small tests, yet scales to support complex functional testing for applications and libraries. It is a mature full-featured Python testing tool.
Selenium automates browsers. That's it! What you do with that power is entirely up to you. Primarily, it is for automating web applications for testing purposes, but is certainly not limited to just that. Boring web-based administration tasks can (and should!) also be automated as well.
See all alternatives

RSpec's Followers
113 developers follow RSpec to keep up with related blogs and decisions.
Janani K
Joseph Lin
jc 85
Luj谩n Fernaud
Liam van Vliet
Ryan Weald