# RSpec RSpec is a behavior-driven development framework for Ruby that provides tools for writing and running executable examples. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## From slow tests to slow production: Debugging with Stackprof DevFeed: [From slow tests to slow production: Debugging with Stackprof]() Original publisher: [Read original article]() Published: 2026-08-13T00:00:00Z Content type: tutorial Language: en Sources: [Aha! Engineering Blog]() Topics: [debugging](), [Tooling](), [RSpec](), [Databases]() Tags: [ci](), [cpu-time](), [database](), [debugging](), [logs](), [overhead](), [performance](), [production-debugging](), [profiling](), [rspec](), [snapshots](), [tests](), [timing]() ### AI overview An investigation into tests that became six times slower traces the stall to code generating example data and Active Record callbacks. The article explains using Stackprof with RSpec to profile the test, including I/O time, and reports that the test spent 71% of its time sleeping. ### Source excerpt One morning, a developer announced in our Slack channel that some tests were failing on our main branch. The cause of the failures was not obvious. No recent PRs seemed related, and neither the code nor the tests had changed in a long time. The test ## Upgrading Rails 4.2 to Rails 8: Count Sites, Not Warnings DevFeed: [Upgrading Rails 4.2 to Rails 8: Count Sites, Not Warnings]() Original publisher: [Read original article]() Published: 2026-08-08T00:00:00Z Content type: tutorial Language: en Sources: [Gaurav Sarma's Blog]() Topics: [Rails](), [upgrade](), [version](), [Test coverage](), [RSpec](), [Docker Compose](), [Ruby]() Tags: [coverage](), [docker-compose](), [rails](), [rspec](), [ruby](), [upgrade](), [version]() ### AI overview An account of upgrading a multi-tenant JSON API from Rails 4.2.7.1 to Rails 8. The author argues that estimates focused on version gates missed the actual risks, and describes how characterization tests, an extracted frontend, and containerized development reduced the work. ### Source excerpt . [Upgrading Rails 4... ## Writing expressive RSpec tests for Ruby objects and Rails views DevFeed: [Writing expressive RSpec tests for Ruby objects and Rails views]() Original publisher: [Read original article]() Author: Simon Fish Published: 2026-07-07T13:26:00Z Content type: tutorial Language: en Sources: [FreeAgent]() Topics: [RSpec](), [Testing](), [Ruby](), [Rails](), [render]() Tags: [rails](), [render](), [rspec](), [ruby](), [ruby-on-rails](), [testing](), [tooling]() ### AI overview The article explains how to use RSpec expressively to separate test phases, clarify expected behavior, and document interfaces. It also discusses why this approach needs adjustment when testing Rails views, which are rendered templates rather than ordinary Ruby objects. ### Source excerpt Using RSpec's functionality expressively helps to draw focus to the right parts of a test, but it's not always easy to understand how best to use it. ## Making RSpec Tests More Robust DevFeed: [Making RSpec Tests More Robust]() Original publisher: [Read original article]() Published: 2020-07-19T12:00:00Z Content type: tutorial Language: en Sources: [Jake Yesbeck]() Topics: [RSpec](), [Ruby](), [Testing](), [Mocking](), [API](), [client](), [HTTP]() Tags: [api](), [code](), [framework](), [mocking](), [ruby](), [testing](), [tests]() ### AI overview This article explains how an RSpec test for Ruby API client code can pass even after the tested method is removed. It shows that mocking the method under test may override its implementation and hide a broken contract. The article recommends stubbing the HTTP client response so the test verifies the request behavior without making a real HTTP request. ### Source excerpt RSpec is a popular framework for testing Ruby code. With an expect assertion, a developer can make sure their code calls the proper method or an acceptable result is returned. The expect().to receive matcher in a test overrides the default implementation and can cause some unintended side effects. To demonstrate this potential problem, assume a very simple API client exists that can update models. Testing an API Client An example api_client.rb class defines a single put method that calls the underlying API with a Faraday connection. # api_client.rb class APIClient def put(url, body) client.put(url, body) end private def client Faraday.new('https://some-cool-api.com') end end Inheriting from api_client.rb is my_model.rb which defines an update method. # my_model.rb class MyModel < APIClient def update(payload) put('/my_models/1', payload) end end A typical test for the update method on MyModel in RSpec might look like: # my_model_spec.rb describe MyModel do describe 'update' do it 'updates the model' do expect(subject).to receive(:put) subject.update({ foo: :bar }) end end end The subject in the above test is MyModel.new and is expected to receive the method put. Since MyModel#update calls the put method, this seems like a reasonable test. $: rspec my_model_spec.rb . Finished in 0.0054 seconds (files took 0.07101 seconds to load) 1 example, 0 failures Running the test produces a passing result, the MyModel class calls its parent method correctly and all is well. Until something changes that the test is unable to detect. Breaking the Contract If MyModel's contract changes, the test should fail. If, for instance, the put method on the APIClient class is removed or commented out, the update method on MyModel would no longer work. # api_client.rb class APIClient # def put(url, body) # client.put(url, body) # end private def client Faraday.new('https://some-cool-api.com') end end However, the test still passes despite this method being removed. $: rspec my_model_spec.rb . ## A Few RSpec Helpful Hints DevFeed: [A Few RSpec Helpful Hints]() Original publisher: [Read original article]() Published: 2017-07-12T12:00:00Z Content type: tutorial Language: en Sources: [Jake Yesbeck]() Topics: [RSpec](), [Testing](), [Ruby](), [Code]() Tags: [code](), [developer](), [ruby](), [testing](), [tests]() ### AI overview This tutorial presents practical RSpec techniques for writing Ruby tests that are readable, reusable, and easier to maintain. It covers subject and let variables, loose expectations, argument matchers, and hash matchers. ### Source excerpt Two main frameworks dominate the Ruby testing world: Rspec and MiniTest. RSpec is a very expressive testing framework with many great features and helpers to make tests readable. When writing RSpec tests, here are just a few not so obvious hints that could make tests even easier to write, read, and maintain. Assuming a system exists with Books and Authors, let's utilize these hints to make testing easy. class Book attr_reader :title, :genre def initialize(title, genre) @title = title @genre = genre end end class Author attr_reader :books def initialize(name, books) @name = name @books = Array(books) end def has_written_a_book? !books.empty? end end subject and let Variables A great way to keep specs DRY and readable are via subject and let variable declarations. For example, if we want to assert an Author has a name, a test without let and subject variables might look something like: describe Author do before do @book_genre = 'Historical Fiction' @book_title = 'A Tale of Two Cities' @book = Book.new(@book_genre, @book_title) @author_name = 'Charles Dickens' @author = Author.new(@author_name, [@book]) end describe '#name'do it 'has a name set' do expect(@author.name).to eq(@author_name) end end end While correct, additional tests asserting number of books, a different name, or other things about this Author could become very verbose. Instead, we can introduce subject and let variables to keep things DRY and reusable: describe Author do let(:book_genre) { 'Historical Fiction' } let(:book_title) { 'A Tale of Two Cities' } let(:book) { Book.new(book_genre, book_title) } let(:book_array) { [book] } let(:author_name) { 'Charles Dickens' } subject { Author.new(author_name, book_array) } describe '#name'do it 'has a name set' do expect(subject.name).to eq(author_name) end end describe '#books' do context 'with books' do it 'has books set' do expect(subject.books).to eq(book_array) end end context 'without books' do context 'books variable is nil' do let(:book_array) { nil } ## Spock tests grouping using @Category from junit DevFeed: [Spock tests grouping using @Category from junit]() Original publisher: [Read original article]() Published: 2017-01-14T00:00:00Z Content type: tutorial Language: en Sources: [Paweł Chudzik]() Topics: [Gradle](), [Testing](), [RSpec]() Tags: [code](), [development](), [gradle](), [how-to](), [junit](), [testing](), [tests]() ### AI overview This tutorial explains how to group Spock tests with JUnit @Category and configure those groups in Gradle. It uses marker interfaces and a helper class to select which test groups run, allowing slower database tests to be skipped during unrelated development work. ### Source excerpt When the project gets bigger and bigger there should be more and more tests. In the perfect world, all tests should be executed really fast, but life is far from perfect and sometimes some tests are slow. When using Gradle + Spock combination we have few ways of deciding how to group tests. I'm going to explore junit @Category in combination with Spock and grade. Read more ## How to Write Future-proof Mocks in RSpec 3 DevFeed: [How to Write Future-proof Mocks in RSpec 3]() Original publisher: [Read original article]() Published: 2015-11-22T12:00:00Z Content type: tutorial Language: en Sources: [Jake Yesbeck]() Topics: [RSpec](), [Development](), [Code]() Tags: [code](), [development](), [tests]() ### AI overview This tutorial explains how to write future-proof mocks in RSpec 3. It demonstrates how ordinary doubles can allow tests to pass even after an external service changes its method signature, and recommends verifying doubles to ensure mocked methods exist on the underlying object. ### Source excerpt Tests are an important component in most software applications. Whether tests drive the development, or are strapped on after the fact, tests need to be reliable for future development to progress. An application's complexity rises with time. During and after this increase, a rock solid test suite is crucial. Let the Dogs Out Given an application that deals with Dogs: class Dog end Keeping track of grooming statistics about this application's dogs is the obvious cash cow. But that sounds very tedious and complicated, so we can assume that a GroomingService exists that exposes a single Groomer object: module GroomingService class Groomer def initialize(dog) @dog = dog end def groom # Some complex grooming logic end end end This service was included by the groomer gem and will become a core piece of the application. To keep everyone in the project sane and well rested, a robust spec suite is needed. Spec It Up Using RSpec and the GroomingService, a very basic test can be written to make sure the code works as expected. Introducing the GroomingService into the Dog class could look like: class Dog def groom GroomingService::Groomer.new(self).groom end end The first test should be to make sure that when the groom method on a Dog is called, it initializes and calls groom out to the GroomService::Groomer object. When asserting that a certain set of methods is called on a particular object, the built in RSpec double method is very handy. The double method returns a stand-in object to assert allow and expect messages against. Any method that is called on the test double which is not explicitly allowed or expected results in an error. describe Dog do subject { described_class.new } describe '#groom' do let(:groomer) { double(GroomingService::Groomer) } it 'initializes and calls groom' do expect(GroomingService::Groomer).to receive(:new) { groomer } expect(groomer).to receive(:groom) subject.groom end end end As expected, this test passes beautifully: $: rspec dog_spec.rb Dog ## Faster Ruby Testing: Only Test What Matters DevFeed: [Faster Ruby Testing: Only Test What Matters]() Original publisher: [Read original article]() Published: 2015-08-02T12:00:00Z Content type: tutorial Language: en Sources: [Jake Yesbeck]() Topics: [Testing](), [RSpec](), [Rails](), [Ruby](), [Database](), [Development]() Tags: [activerecord](), [bugs](), [code](), [database](), [development](), [ruby](), [ruby-on-rails](), [speed](), [testing](), [tests]() ### AI overview This article explains how to make Ruby on Rails tests faster by keeping each test within the responsibility of the method under test. Using RSpec examples, it recommends avoiding unnecessary database writes and asserting method behavior directly when persistence is handled elsewhere. ### Source excerpt Automated testing is important. Fast, exhaustive automated testing is even more important. Tests are responsible for ensuring the code you spend hours creating actually works. A great test suite can be a safeguard against bugs, a directional guide towards extending the code, and an accurate measurement of the codebase's health. The key to writing good tests is understanding where pieces of responsibility begin and end. Maintaining small concise automated tests can make all the difference. Speed is King Aside from the general importance of short feedback cycles, a fast test suite will greatly improve your work-flow and mood. Conversely, a slow test suite can make your development cycle a living nightmare. How many unfortunate software artisans have dealt with something like: Bleh! What a horrible thing to deal with. What, am I supposed to just wait 5 whole minutes every time I want to test my system? A test suite this slow is simply unacceptable. So what could be causing this slowness? More than likely, a number of tests in this application are doing too much. To try and replicate and solve this problem, let's assume we have a Ruby on Rails application we test using RSpec. Testing Database Models is Slow We can assume that there exists a very important class called MyAwesomeClass: class MyAwesomeClass < ActiveRecord::Base def assign_and_save! saved_on_the_weekend = weekend? self.save! end def weekend? Time.now.saturday? || Time.now.sunday? end end If we wanted to test that the assign_and_save! method works correctly, we might write a test like: describe '#assign_and_save!' do it 'assigns and saves' do awesome_test = MyAwesomeClass.new expect do awesome_test.assign_and_save! end.to change(MyAwesomeClass, :count).by(1) expect(awesome_test.saved_on_the_weekend).to_not be_nil end end These tests make sure that the model is saved correctly to the database and a value is assigned to saved_on_the_weekend. However, the test code is overstepping the boundaries of the method i ## Stricter Tests for Expectations Set on Nil in RSpec DevFeed: [Stricter Tests for Expectations Set on Nil in RSpec]() Original publisher: [Read original article]() Author: Square Engineering Published: 2015-06-19T07:00:00Z Content type: tutorial Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [RSpec](), [Testing](), [Ruby](), [bug](), [Code review]() Tags: [bug](), [code-review](), [engineering](), [ruby](), [testing](), [tests]() ### AI overview This article explains how Square implemented stricter RSpec behavior so tests fail when message expectations are set on nil, helping catch false positives that warnings alone may leave unnoticed. ### Source excerpt Make your RSpec tests fail when expectations are set on nil. ## Short Feedback Cycles DevFeed: [Short Feedback Cycles]() Original publisher: [Read original article]() Published: 2015-06-07T12:00:00Z Content type: article Language: en Sources: [Jake Yesbeck]() Topics: [Testing](), [RSpec](), [Development](), [Code](), [Refactoring]() Tags: [code](), [development](), [refactoring](), [testing](), [tests]() ### AI overview The article explains how automated tests and short feedback cycles improve software development. It distinguishes unit and integration tests, emphasizes fast test suites for preventing bugs and easing feature work and refactoring, and describes using Guard to run RSpec tests automatically when code changes. ### Source excerpt Forty-two days into my year of commits initiative has come and gone. With it, I have found some great processes for making my contributions efficient and effective. Feedback is extremely important when writing software. After all, the code you write is probably designed to work, right? Right. A good way to verify correctness in your software is through automated tests. These can either be unit tests for specific methods and functions or integration tests; those that make sure a complete code path behaves as expected. Regardless, we write these tests to ensure our code works now and in the future. "In the future" is where I have started to contribute to projects. Good projects have test files that the original author(s) provide. Great projects have fast test files that the original author(s) provide. Fast tests provide short feedback cycles. Short feedback cycles prevent bugs and help make new feature development and refactoring much more painless. Feedback governs our behaviors in and outside the development world. Without it, we would not be as efficient or effective at the tasks that are important to us. From writing software to training for a half marathon, feedback matters a great deal. In a recent contribution of mine, I relied heavily on automated testing and short feedback cycles. It was important to me that I was able to identify how the specs were changing as I upgraded them to RSpec 3. I used Guard to help run my tests automatically when any of the code changed. Guard is a tool to automatically run your automated test files as you are making changes to the code. Guard has been around for a long time. I chose to use it due to how simple it is to set up. All you need to do is include the guard-rspec gem in your repository create a Guardfile. An example Guardfile (which exists in the root of your repository) would look something like this: guard :rspec, cmd: 'rspec', notification: false do watch(%r{^spec/.+_spec\.rb$}) watch(%r{^lib/(.+)\.rb$}) { |m| "spec/li ## Kochiku: CI for long test suites DevFeed: [Kochiku: CI for long test suites]() Original publisher: [Read original article]() Author: Square Engineering Published: 2013-09-06T16:04:00Z Content type: release Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [ci](), [GitHub Actions](), [Rails](), [Ruby](), [Cucumber](), [RSpec](), [Amazon EC2](), [Selenium]() Tags: [build](), [ci](), [continuous-integration](), [ec2](), [engineering](), [rails](), [ruby](), [selenium](), [tests](), [unit-tests]() ### AI overview Square introduces Kochiku, a continuous integration system that partitions long test suites into distributable chunks and runs them through a queue of build workers. ### Source excerpt A new Continuous Integration tool from Square ## Testing Named Scopes DevFeed: [Testing Named Scopes]() Original publisher: [Read original article]() Author: Square Engineering Published: 2010-10-14T16:00:00Z Content type: tutorial Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [Testing](), [Rails](), [Ruby](), [RSpec](), [SQL](), [Code]() Tags: [activerecord](), [code](), [engineering](), [implementation](), [rails](), [ruby](), [scopes](), [sql](), [test](), [testing]() ### AI overview This tutorial presents a helper for testing Rails ActiveRecord named scopes. It uses concise Ruby conditions with RSpec to verify that a scope returns the expected subset, including cases involving SQL, joins, or subqueries. ### Source excerpt Test your named scopes with Rail code