Test Data
FactoryBot (formerly FactoryGirl) is the de facto standard for test data in Ruby and Rails applications. It replaced fixture files for most teams because factories are composable, explicit, and stay synchronized with your models as schemas evolve. If you've inherited a Rails codebase with hundreds of YAML fixtures
Ruby on Rails
FactoryBot is more than a replacement for fixtures. Advanced patterns—traits, transient attributes, build strategies, and lifecycle callbacks—let you create precisely the objects your tests need without duplicating setup logic or hitting the database unnecessarily. Most Rails developers learn enough FactoryBot to define a basic factory and move on.
Ruby
FactoryBot is the standard library for generating test data in Rails applications. It replaces fixtures with a programmable approach: define templates for your models, then build or create instances with exactly the attributes each test needs. This guide covers everything from basic setup to advanced patterns. Installation and Setup Add
Ruby
SimpleCov is the standard code coverage library for Ruby. It hooks into Ruby's Coverage module, tracks which lines and branches your tests exercise, and generates HTML reports so you can see exactly what's untested. Installation # Gemfile group :test do gem 'simplecov', require: false end
Testing
Example-based testing asks "does this specific input produce this specific output?" Property-based testing asks "does this output have this characteristic for all possible inputs?" Property testing generates hundreds of random examples and finds the edge cases you wouldn't think to write manually.
Ruby on Rails
RSpec shared examples and shared contexts eliminate massive test duplication when multiple models or controllers share the same behavior. This post covers advanced patterns including custom matchers, metadata tagging, and composable shared contexts that scale across large Rails codebases. Test suites grow fast. A Rails app with a dozen models,
Ruby
When multiple objects share the same interface or behaviour, copy-pasting test cases is a maintenance trap. RSpec's shared examples and shared contexts let you write that behaviour once and include it wherever it applies. Shared Examples Defining shared examples # spec/support/shared_examples/paginatable.rb RSpec.shared_
Ruby
RSpec is the dominant testing framework in the Rails ecosystem. Its BDD-style syntax encourages you to write tests that read like specifications, which makes test failures easier to diagnose and test suites easier to navigate. This tutorial walks through everything you need to get RSpec working well in a
Ruby
Test doubles let you isolate the unit under test by replacing collaborators with controlled stand-ins. RSpec ships with a full mocking library — no extra gems needed. This guide covers everything from basic stubs to strict message expectations. The Four Types of Test Doubles Type Purpose Double Pure stand-in
Testing
When tests contain domain concepts that don't map cleanly to built-in RSpec matchers, the result is verbose assertions that reveal implementation rather than intent. Custom matchers let you express what the test means rather than how it works. A matcher like be_a_valid_invoice communicates more
Ruby
Rails ships with a testing framework built in. Most teams either use it as-is (Minitest) or replace it with RSpec. Both are solid choices, but they have different philosophies and different ecosystems. This guide covers what you need to know to test a Rails application effectively — regardless of which
Ruby
System tests are the closest thing to a real user clicking through your application. They drive a browser, fill in forms, click buttons, and assert what the user sees. Rails has built-in support for system tests via Capybara, and this guide covers how to use them effectively. What System