\nColophon

The original cover image “Old truck in early morning light stock photo”\nis by iStockphoto contributor Habman_18.

",{"_211":212,"_44":45,"_48":49,"_46":47,"_66":67,"_213":214,"_250":209},"previewContent","

\n Preface to this edition\n
\n 1. Introduction\n
- \n Confident testing\n
- \n Why RSpec?\n
- \n Who should read this book\n
- \n My testing philosophy\n
- \n How the book is organized\n
- \n Downloading the sample code\n
- \n Code conventions\n
- \n Discussion and errata\n
- \n A note about gem versions\n
- \n A note about styling\n
- \n About the sample application\n
\n
\n 2. Setting up RSpec\n
- \n Dependencies\n
- \n Test database\n
- \n RSpec configuration\n
- \n The rspec binstub\n
- \n Try it out!\n
- \n Summary\n
- \n Exercises\n
\n
\n 3. Model specs\n
- \n Anatomy of a model spec\n
- \n Creating a model spec\n
- \n The RSpec syntax\n
- \n Testing validations\n
- \n Testing instance methods\n
- \n Testing class methods and scopes\n
- \n Testing all the cases\n
- \n More about matchers\n
- \n Summary\n
- \n Exercises\n
\n
\n About Everyday Rails\n
\n About the author\n
\n Colophon\n

\nPreface to this edition

\n\n

Thank you for picking up this latest version of Everyday Rails Testing with RSpec. It’s been awhile! As always, Rails and RSpec continue to evolve, but are still your best bet for quickly building (and testing) robust, scalable, full-stack web applications. But the biggest change to our field between 2017 (the last time I released a major update) and today is artificial intelligence.

\n\n

Now, this is not a book about AI. In fact, this is the only time I’ll even mention it. Can you use AI to write your tests? Sure. Can you expect them to be good tests? Sometimes. But how do you tell the good tests apart from the bad?

\n\n

AI-assisted programming is likely not going away. And whether or not you choose to use new tools like Claude Code or GitHub Copilot in your daily workflow, we all need to keep core skills sharp: Clean, ideomatic code, fundamentals of software design, and test-driven development.

\n\n

Good tests don’t just prove your software works. Good tests also prove your software is sustainable for the long haul. Understanding how and where to write these tests takes time–and it’s up to you, as the human in the room with your AI agentic programming buddy, to make those tests happen.

\n\n

It’s an exciting time to be a software developer! I hope Everyday Rails Testing with RSpec inspires you toward thoughtful software design and development.

\n\n

Aaron Sumner
\nSaint Louis, MO, USA
\nSeptember, 2025

\n\n\n

\n1. Introduction

\n\n

Ruby on Rails and automated testing go hand in hand. Rails ships with a built-in test framework. It automatically creates boilerplate test files when you use generators, ready for you to fill in with your own tests. That’s pretty awesome, if you ask me.

\n\n

Yet, many people developing in Rails are still either not testing their projects at all, or at best, only adding a few token specs on basic things that may not even be useful, or informative. Perhaps working with Ruby or opinionated web frameworks is a novel enough concept, and adding an extra layer of work seems like just that–extra work! Or maybe there is a perceived time constraint–spending time on writing tests takes time away from writing the features our clients or bosses demand. Or maybe the habit of defining test as the practice of clicking links in the browser is just too hard to break.

\n\n

I’ve been there. As an engineer, I have problems to solve. And, typically, I find solutions to these problems in building software. I’ve been developing web applications since 1995. For a long time, I worked as a solo developer on shoestring, public sector projects. Aside from some structured exposure to BASIC as a kid, a little C++ in college, and a wasted week of Java training in my second grown-up job outside of college, I’ve never had any honest-to-goodness schooling in software development. In fact, it wasn’t until 2005, when I’d had enough of hacking ugly spaghetti-style PHP code, that I sought out a better way to write web applications.

\n\n

I’d looked at Ruby before, but never had a serious use for it until Rails began gaining steam. There was a lot to learn–a new language, an actual architecture, and a more object-oriented approach. Even with all those new challenges, though, I was able to create complex applications in a fraction of the time it took me in my previous, framework-less efforts. I was hooked!

\n\n

\nConfident testing

\n\n

But early Rails books and tutorials focused more on development speed (build a blog in 15 minutes!) than on good practices like testing. If they covered testing at all, they generally reserved it for a chapter toward the end. Newer educational resources on Rails have addressed this shortcoming, and demonstrate how to test applications from the beginning. Countless books now exist specifically on the topic of testing. But without a sound approach to the testing side, many developers–especially those in a similar position to the one I was in–may find themselves without a consistent testing strategy. If there are any tests at all, they may not be reliable, or meaningful. Such tests don’t lead to developer confidence.

\n\n

My first goal with this book is to introduce you to a consistent strategy that works for me–one that you can then, hopefully, adapt to make work consistently for you, too. If I’m successful, then by reading this book, you’ll test with confidence. You’ll be able to make changes to your code, knowing that your test suite has your back and will let you know if something breaks.

\n\n

\nWhy RSpec?

\n\n

I have nothing against other Ruby testing frameworks. If the default MiniTest framework helps you confidently write sustainable test suites, that’s great!

\n\n

For me, RSpec’s capacity for specs that are readable, without being overly cumbersome, is a winner. I’ll talk more about this later in the book, but I’ve found that with a little coaching, even most non-technical people can read a spec written in RSpec and understand what’s going on. It’s expressive in such a way that using RSpec to describe how I expect my software to behave has become second nature. The syntax flows from my fingers, and is pleasant to read in the future when I’m making changes to my software.

\n\n

My second goal with this book is to help you feel comfortable with the RSpec functionality and syntax you’re most likely to use on a regular basis. RSpec is a complex framework, but like many complex systems, you’ll often find yourself using 20 percent of the available functionality for 80 percent of your work. With that in mind, this is not a complete guide to RSpec or companion libraries like Capybara. It instead focuses on the tools I’ve used for years to test my own Rails applications. It will also introduce you to common patterns so that, when you run into an issue that’s not covered in the book, you’ll be able to intelligently look for solutions and not get stuck.

\n\n

\nWho should read this book

\n\n

If Rails is your first foray into a full-stack application framework, and your past programming experience didn’t involve any testing to speak of, this book will hopefully help you get started. If you’re really new to Rails, you may find it beneficial to review coverage of development and basic testing. My favorite is Agile Web Development with Rails 7 by Sam Ruby; lots of people like Michael Hartl’s Rails Tutorial as well. My book assumes you’ve got some basic Rails skills under your belt. In other words, it won’t teach you how to use Rails, and it won’t provide a ground-up introduction to the testing tools built into the framework. Instead, we’re going to be installing RSpec and a few extras to make the testing process as easy as possible to comprehend and manage. So if you’re new to Rails, check out one of those resources first, then come back to this book.

\n\n\n\n

If you’ve been developing in Rails for a little while, but testing is still a foreign concept, then this book is for you! I was in your position for a long time, and the techniques I’ll share here helped me improve my test coverage and think more like a test-driven developer. I hope they’ll do the same for you.

\n\n

Specifically, you should probably have a grasp of

\n\n

Server-side Model-View-Controller application conventions, as used in Rails
Bundler for gem dependency management
How to work with the Rails command line

\n\n

If you’re already familiar with using MiniTest, or even RSpec itself, and already have a workflow in place that gives you confidence, you may be able to fine-tune some of your approach to testing your applications. I hope you’ll also learn from my opinionated approach to testing, and how to go from testing your code to testing with purpose.

\n\n

This is not a book on general testing theory, and it doesn’t dig too deeply into maintenance and performance issues that can creep into legacy software over time. Other books may be of more use on those topics. Refer to More Testing Resources for Rails at the end of this book for links to these and other books, websites, and testing tutorials.

\n\n

\nMy testing philosophy

\n\n

What kind of testing is best–unit tests, or integration? Should I practice test-driven development, or behavior-driven development (and what’s the difference, anyway)? Should I write my tests before I write code, or after? Or should I even bother to write tests at all?

\n\n

Discussing the right way to test your Rails application can invoke major shouting matches amongst programmers. Yes, there is a right way to do testing–but if you ask me, there are degrees of right when it comes to testing. My approach focuses on the following basic beliefs:

\n\n

Tests should be reliable.
Tests should be easy to write.
Tests should be easy to understand–today, and in the future; by you and your collaborators.

\n\n

In summary: Tests should give you confidence as a software developer. If you mind these three factors in your approach, you’ll go a long way toward having a sound test suite for your application–not to mention becoming an honest-to-goodness practitioner of Test-Driven Development.

\n\n

Yes, there are some tradeoffs–in particular:

\n\n

We’re not focusing on speed, though we will talk about it later.
We’re not focusing on overly DRY code in our tests. But in tests, that’s not necessarily a bad thing. We’ll talk about this, too.

\n\n

In the end, though, the most important thing is that you’ll have good tests–and reliable, understandable tests are a great way to start, even if they’re not quite as optimized as they could be. This is the approach that finally got me over the hump between writing a lot of application code, calling a round of browser-clicking “testing,” shipping to production, and hoping for the best. There’s a better way: Taking advantage of a fully automated test suite and using tests to drive development and ferret out potential bugs and edge cases before users spot them.

\n\n

And that’s the approach we’ll take in this book.

\n\n

\nHow the book is organized

\n\n

In Testing Rails with RSpec I’ll walk you through taking a basic Rails application from completely untested to respectably tested with RSpec. The book covers Rails 7.1 and RSpec 3.12. Many of the concepts apply to older and newer versions of each, albeit with slightly different syntax.

\n\n

The book starts with RSpec installation in an existing Rails application. From there, we build a test suite bit by bit, starting with small, isolated tests and working out to broader, more complex testing scenarios. This is the same, step-by-step process I used to get better at testing my own software. I strongly recommend working through the exercises in your own applications–it’s one thing to follow along with a tutorial; it’s another thing entirely to apply what you learn to your own situation. We won’t be building an application together in this book, just exploring code patterns and techniques. Take those techniques and make your own projects better!

\n\n

\nDownloading the sample code

\n\n

You can grab the sample code at https://everydayrails.com/rspecbook. The provided Zip file contains snapshots of the sample application and its test suite as it grows, chapter to chapter. For example, the 02-models directory includes the Rails application itself, and the tests added in chapter 2.

\n\n

\nCode conventions

\n\n

I’m using the following setup for this application:

\n\n

\nRails 7.1: The latest version of Rails is the big focus of this book. As far as I know, most of the techniques I’m using will apply to any version of Rails from 6.0 onward. Your mileage may vary with some of the code samples, but I’ll do my best to let you know where things might differ.
\nRuby 3.2: Any version of Ruby 3 should work.
\nRSpec 3.12: RSpec 3.0 was released in spring, 2014, and has been largely stable since that time. Earlier versions used a significantly different syntax we won’t cover in this edition of the book.

\n\n

If something’s particular to these versions, I’ll do my best to point it out. If you’re working from an older version of Rails, RSpec, or Ruby, previous versions of the book are available as free downloads through Leanpub with your paid purchase of this edition. They’re not feature-for-feature identical, but you should hopefully be able to see some of the basic differences.

\n\n

Again, this book is not a traditional tutorial! The code provided here isn’t intended to walk you through building an application. It’s here to help you understand and learn testing patterns and habits to apply to your own Rails applications. In other words, you can copy and paste, but it’s probably not going to do you a lot of good in the long run.

\n\n

\nDiscussion and errata

\n\n

I’ve put a lot of time and effort into making sure Testing Rails with RSpec is as error-free as possible, but you may find something I’ve missed. If that’s the case, head on over to the issues section for the source on GitHub to share an error or ask for more details: https://github.com/everydayrails/rspec-sample-rails-7.1/issues

\n\n

\nA note about gem versions

\n\n

The gem versions used in this book and the sample application are current as I write this Rails 7.1 edition, in 2024. Of course, any and all may update frequently, so keep tabs on them on Rubygems.org, GitHub, and your favorite Ruby news feeds for updates.

\n\n

\nA note about styling

\n\n

Many of the code samples included in this book are based from code created by generators. As a result, you may see samples with mismatching styles–for example, use of single quotes and double quotes in the same file. In the interest of keeping differences between what’s generated and what matters for learning RSpec, I’ve elected to leave styles in generated code as-is, but will otherwise generally follow conventions as defined by Standard Ruby.

\n\n

\nAbout the sample application

\n\n

Meet TasteDrivenDishes, the latest social site for finding and sharing your favorite recipes with users around the world! We’d better get a test suite in place before the site hits the front page of Hacker News–better for us to catch (and fix) bugs before our users and investors do.

\n\n

To start, TasteDrivenDishes includes the following features:

\n\n

A user can browse recipes and filter by category.
A user can create an account to add their own recipes.
A signed-in user can mark recipes as favorites.
A user’s account has an avatar, provided by the Dicebear service.
A developer can access a public API to develop external client applications.

\n\n

Up to this point, I’ve intentionally avoided writing tests for the application (see the 01-untested folder in the sample code download). This means I have a test directory full of untouched test files and data setup. I could run bin/rails test, and perhaps some of these tests would even pass. But since this is a book about RSpec, we’ll delete this folder, set up Rails to use RSpec instead, and build out a reliable test suite. That’s what we’ll walk through in this book.

\n\n

First things first: We need to configure the application to recognize and use RSpec. Let’s get started!

\n\n\n

\n2. Setting up RSpec

\n\n

TasteDrivenDishes is currently functioning. At least we think it’s functioning. Our only proof of that is we clicked through the links, made a few fake accounts and recipes, and added and edited data through the web browser.

\n\n

Ship it, right?

\n\n

Of course, this approach doesn’t scale as we add features. Before we go any further, let’s pause feature development and add an automated test suite, with RSpec at its core. Over the remainder of this book, we’ll add coverage to TasteDrivenDishes, starting with RSpec, and adding other testing libraries as necessary to round out the suite.

\n\n

Once upon a time, it took considerable effort to get RSpec and Rails to work together. That’s not the case anymore, but we’ll still need to install a few things and tweak some configurations before we start adding specs.

\n\n

In this chapter, we’ll complete the following tasks:

\n\n

We’ll start by using Bundler to install RSpec.
Next, we’ll check for a test database and install one, if necessary.
Finally, we’ll configure RSpec to run the test suite!

\n\n\n\n

\nDependencies

\n\n

Since RSpec isn’t included in a default Rails application, we’ll need to take a moment to install it. We’ll use Bundler to add the dependency. If you don’t already have a terminal command line open in the application, open one now. Then, at the command line prompt, type:

\n\n

bundle add rspec-rails --version \"~> 6.1.2\" --group \"development, test\"\n

\n\n\n\n

Note that we’re only installing RSpec for use in the application’s development and test environments. It won’t be installed when deploying the application to production. We’ve also locked the version so that Bundler will install any version of the rspec-rails gem equal to or greater than 6.1.2, but not 6.2 or newer.

\n\n

Technically, we’re installing the rspec-rails library, which includes rspec-core and a few other standalone gems. If you were using RSpec to test a a non-Rails Ruby application, you might install these gems individually. rspec-rails packages them together into one convenient installation, along with some Rails-specific conveniences that we’ll begin talking about soon.

\n\n

Our application now has the first building block necessary to establish a solid test suite. Next up: Creating our test database.

\n\n

\nTest database

\n\n

For the purposes of teaching you about RSpec without much extra overhead, TasteDrivenDishes uses SQLite for its database backend.

\n\n

If you’re adding specs to an existing Rails application, there’s a chance you’ve already got a test database on your computer. If not, here’s how to add one.

\n\n

Open the file config/database.yml to see which databases your application is ready to talk to. If you haven’t made any changes to the file, you should see something like the following:

\n\n

config/database.yml

1 test:\n2   <<: *default\n3   database: db/test.sqlite3\n

\n\n\n\n

Or this if you’re using MySQL or PostgreSQL:

\n\n

config/database.yml

1 test:\n2   <<: *default\n3   database: recipes_test\n

\n\n\n\n

If not, add the necessary code to config/database.yml now, replacing recipes_test with the appropriate name for your application.

\n\n\n\n

To ensure there’s a database to talk to, run the following rake task:

\n\n

$ bin/rails db:create:all\n

\n\n\n\n

If you didn’t yet have a test database, you do now. If you already had one, the rails task politely informs you that the database already exists–no need to worry about accidentally deleting a previous database. Now let’s configure RSpec itself.

\n\n

\nRSpec configuration

\n\n

Now we can add a spec folder to our application and add some basic RSpec configuration. We’ll install RSpec with the following command line directive:

\n\n

$ bin/rails generate rspec:install\n

\n\n\n\n

And the generator reports:

\n\n

Running via Spring preloader in process 28211\n      create  .rspec\n      create  spec\n      create  spec/spec_helper.rb\n      create  spec/rails_helper.rb\n

\n\n\n\n

We’ve now got a configuration file for RSpec (.rspec), a directory for our spec files as we create them (spec), and two helper files where we’ll eventually customize how RSpec will interact with our code (spec/spec_helper.rb and spec/rails_helper.rb). These last two files include lots of comments to explain what each customization provides. You don’t need to read through them right now, but as RSpec becomes a regular part of your Rails toolkit, I strongly recommend reading through them and experimenting with different settings. That’s the best way to understand what they do.

\n\n

Next–and this is optional–I like to change RSpec’s output from the default format to the easy-to-read documentation format. This makes it easier to see which specs are passing and which are failing as your suite runs. It also provides an attractive outline of your specs for–you guessed it–documentation purposes. Open the .rspec file that was just created, and edit it to look like this:

\n\n

.rspec

--require spec_helper\n--format documentation\n

\n\n\n\n

Alternatively, you can also add the --warnings flag to this file, too. When warnings are enabled, RSpec’s output will include any and all warnings thrown by your application and gems it uses. This can be useful when developing a real application–always pay attention to deprecation warnings thrown by your tests–but for the purpose of learning to test, I recommend shutting it off and reducing the chatter in your test output. You can always add it back later.

\n\n

\nThe `rspec` binstub

\n\n

Next, let’s install a binstub for the RSpec test runner, just to save ourselves from a bit of typing. We’ll be running the test suite a lot! On your command line, generate the binstub:

\n\n

1 bundle binstubs rspec-core\n

\n\n\n\n

This will create an rspec executable, inside the application’s bin directory. If you don’t want to install the binstub for whatever reason, you can skip this section–just remember to use the bundle exec rspec command wherever I use bin/rspec throughout the book.

\n\n

\nTry it out!

\n\n

We don’t have any tests yet, but we can still check to see if RSpec is properly installed in the app. Fire it up, using that binstub we just created:

\n\n

$ bin/rspec\n

\n\n\n\n

If everything’s installed, you should see output something like:

\n\n

    No examples found.\n\n    Finished in 0.00015 seconds (files took 0.0484 seconds to load)\n    0 examples, 0 failures\n

\n\n\n\n

If your output looks different, go back and make sure you’ve followed the steps outlined above.

\n\n\n\n

\nSummary

\n\n

In this chapter, we added RSpec as a dependency to the application’s development and test environments, and configured a test-only database for our tests to talk to. We also added default configuration files for RSpec.

\n\n

Now we’re ready to write some tests! In the next chapter, we’ll start testing the application’s functionality, starting with its model layer.

\n\n

\nExercises

\n\n

If you’ve got an existing Rails application that needs a test coverage, feel free to begin building a test suite now, following the steps we took to install and configure RSpec in TasteDrivenDishes.
Or, try creating a new Rails app from scratch! It doesn’t need to be fancy or even unique. A simple to-do list or blog is always great for learning, or perhaps a tool to help track items in your favorite collection. Be as creative as you’d like!
\nOr, perhaps you have ideas for features you’d add to TasteDrivenDishes! If that’s the case, take a little time to build them out. They don’t need to be fancy or pretty, but you may want to do this work in a separate copy of the code to avoid conflicts in future chapters.

\n\n

Whichever path you choose, don’t worry about tests yet. If you took the existing Rails app or scratch app route, install and configure RSpec in it now. Make sure you’ve installed the necessary gems and configured for the application. Ensure bin/rspec successfully runs.

\n\n\n

\n3. Model specs

\n\n

With RSpec successfully installed, let’s put it to work and begin building a suite of reliable tests. We’ll get started with TasteDrivenDishes’s core building blocks–its models.

\n\n

In this chapter, we’ll complete the following tasks:

\n\n

First we’ll create model specs for existing models.
Then, we’ll write passing tests for a model’s validations, class, and instance methods, and organize our specs in the process.

\n\n

We’ll create our first spec files for existing models manually. Later, when adding new models to the application, the handy RSpec generators we configured in chapter 2 will generate placeholder files for us.

\n\n\n\n

\nAnatomy of a model spec

\n\n

I think it’s easiest to learn testing at the model level, because doing so allows you to examine and test the core building blocks of an application. Well-tested code at this level provides a solid foundation for a reliable overall code base.

\n\n

To get started, a model spec should include tests for the following:

\n\n

When instantiated with valid attributes, an object of the model should be valid.
Objects that don’t meet validation requirements should not be valid.
Class and instance methods perform as expected.

\n\n

This is a good time to look at the basic structure of an RSpec model spec. I find it helpful to think of them as individual outlines. For example, let’s look at our User model’s simplest requirements:

\n\n

describe User do\n  it \"is valid with an email, password, nickname, and API token\"\n  it \"requires a nickname\"\n  it \"requires a unique nickname\"\n  it \"requires an email\"\n  it \"requires a unique email\"\n  it \"requires a password\"\n  it \"requires an API token\"\n  it \"sets a new user's API token\"\nend\n

\n\n\n\n

We’ll expand this outline in a few minutes, but this gives a lot to work with for starters. It’s a simple spec for an admittedly simple model, but points to our first four best practices:

\n\n

\nIt describes a set of expectations–in this case, what the User model should look like, and how it should behave.
\nEach example (a line beginning with it) only expects one thing. Notice that I’m testing each validation separately. This way, if an example fails, I know it’s because of that specific validation, and I don’t have to dig through RSpec’s output for clues–at least, not as deeply.
\nEach example is explicit. The descriptive string after it is technically optional in RSpec. However, omitting it makes your specs more difficult to read.
\nEach example’s description begins with a verb, not should. Read the expectations aloud: User requires an API token, User requires an email, User sets a new user’s API token. Readability is important, and a key feature of RSpec!

\n\n

With these best practices in mind, let’s build a spec for the User model.

\n\n

\nCreating a model spec

\n\n

In chapter 2, we set up RSpec to automatically generate boilerplate test files whenever we add new models and controllers to the application. We can invoke generators anytime, though. Here, we’ll use one to generate a starter file for our first model spec.

\n\n

Begin by using the rspec:model generator on the command line:

\n\n

$ bin/rails g rspec:model user\n

\n\n\n\n

RSpec reports creating the new file:

\n\n

rails g rspec:model user\n      createÂ  spec/models/user_spec.rb\n

\n\n\n\n

Let’s open the new file and take a look.

\n\n

spec/models/user_spec.rb

1 require 'rails_helper'\n2 \n3 RSpec.describe User, type: :model do\n4   pending \"add some examples to (or delete) #{__FILE__}\"\n5 end\n

\n\n\n\n

The new file gives us our first look at some RSpec syntax and conventions. First, we require the file rails_helper in this file, and will do so in pretty much every file in our test suite. This tells RSpec that we need the Rails application to load, so it can then run the tests contained in the file. Next, we’re using the describe method to list out a set of things a model named User is expected to do. We’ll talk more about pending in chapter 12, when we begin practice test-driven development. For now, happens if we run this, using bin/rspec?

\n\n

User\n  add some examples to (or delete) /Users/asumner/code/examples/recipes/spec/mode\\\nls/user_spec.rb (PENDING: Not yet implemented)\n\nPending: (Failures listed here are expected and do not affect your suite's status)\n\n  1) User add some examples to (or delete) /Users/asumner/code/examples/recipes/s\\\npec/models/user_spec.rb\n    # Not yet implemented\n    # ./spec/models/user_spec.rb:4\n\nFinished in 0.00058 seconds (files took 0.66131 seconds to load)\n1 example, 0 failures, 1 pending\n

\n\n\n\n\n\n

Let’s keep the describe wrapper, but replace its contents with the outline we created a few minutes ago:

\n\n

spec/models/user_spec.rb

 1 require 'rails_helper'\n 2 \n 3 RSpec.describe User, type: :model do\n 4   it \"is valid with an email, password, nickname, and API token\"\n 5   it \"requires a nickname\"\n 6   it \"requires a unique nickname\"\n 7   it \"requires an email\"\n 8   it \"requires a unique email\"\n 9   it \"requires a password\"\n10   it \"requires an API token\"\n11   it \"sets a new user's API token\"\n12 end\n

\n\n\n\n

We’ll fill in the details in a moment, but if we ran the specs right now from the command line (by typing bin/rspec on the command line) the output would be something like:

\n\n

User\n  is valid with an email, password, nickname, and API token (PENDING: Not yet imp\\\nlemented)\n  requires a nickname (PENDING: Not yet implemented)\n  requires a unique nickname (PENDING: Not yet implemented)\n  requires an email (PENDING: Not yet implemented)\n  requires a unique email (PENDING: Not yet implemented)\n  requires a password (PENDING: Not yet implemented)\n  requires an API token (PENDING: Not yet implemented)\n  sets a new user's API token (PENDING: Not yet implemented)\n\nPending: (Failures listed here are expected and do not affect your suite's status)\n\n  1) User is valid with an email, password, nickname, and API token\n    # Not yet implemented\n    # ./spec/models/user_spec.rb:4\n\n  2) User requires a nickname\n    # Not yet implemented\n    # ./spec/models/user_spec.rb:5\n\n  3) User requires a unique nickname\n    # Not yet implemented\n    # ./spec/models/user_spec.rb:6\n\n  4) User requires an email\n    # Not yet implemented\n    # ./spec/models/user_spec.rb:7\n\n  5) User requires a unique email\n    # Not yet implemented\n    # ./spec/models/user_spec.rb:8\n\n  6) User requires a password\n    # Not yet implemented\n    # ./spec/models/user_spec.rb:9\n\n  7) User requires an API token\n    # Not yet implemented\n    # ./spec/models/user_spec.rb:10\n\n  8) User sets a new user's API token\n    # Not yet implemented\n    # ./spec/models/user_spec.rb:11\n\n\nFinished in 0.00086 seconds (files took 0.83556 seconds to load)\n8 examples, 0 failures, 8 pending\n

\n\n\n\n

Great! Eight pending specs. RSpec marks them as pending because we haven’t written any actual code to perform the tests. Let’s do that now, starting with the first example.

\n\n\n\n

\nThe RSpec syntax

\n\n

In 2012, the RSpec team announced a new, preferred alternative to the traditional should, added to version 2.11. Of course, this happened just a few days after I released the first complete version of this book–it can be tough to keep up with this stuff sometimes!

\n\n

This new approach alleviates some technical issues caused by the old should syntax. Instead of saying something should or should_not match expected output, you expect something to or not_to be something else.

\n\n

As an example, let’s look at this sample test, or expectation. In this example, 2 + 1 should always equal 3, right? In the old RSpec syntax, this would be written like this:

\n\n

it \"adds 2 and 1 to make 3\" do\n  (2 + 1).should eq 3\nend\n

\n\n\n\n

The new syntax passes the test value into an expect() method, then chains a matcher to it:

\n\n

it \"adds 2 and 1 to make 3\" do\n  expect(2 + 1).to eq 3\nend\n

\n\n\n\n

If you’re searching Google or Stack Overflow for help with an RSpec question, or are working with an older Rails application, there’s still a good chance you’ll find information using the old should syntax. This syntax still technically works in current versions of RSpec, but you’ll get a deprecation warning when you try to use it. You can configure RSpec to turn off these warnings, but in all honesty, you’re better off learning to use the preferred expect() syntax.

\n\n

So what does that syntax look like in a real example? Let’s fill out that first expectation from our spec for the User model:

\n\n

spec/models/user_spec.rb

 1 require 'rails_helper'\n 2 \n 3 RSpec.describe User, type: :model do\n 4   it \"is valid with an email, password, nickname, and API token\" do\n 5     user = User.new(\n 6       email: \"test@example.com\",\n 7       password: \"password\",\n 8       nickname: \"test\",\n 9       api_token: \"token\"\n10     )\n11 \n12     expect(user).to be_valid\n13   end\n14 \n15   it \"requires a nickname\"\n16   it \"requires a unique nickname\"\n17   it \"requires an email\"\n18   it \"requires a unique email\"\n19   it \"requires a password\"\n20   it \"requires an API token\"\n21   it \"sets a new user's API token\"\n22 end\n

\n\n\n\n

This simple example uses an RSpec matcher called be_valid to verify that our model knows what it has to look like to be valid. We set up an object (in this case, a new-but-unsaved instance of User called user), then pass that to expect to compare to the matcher.

\n\n

Now, if we run bin/rspec from the command line again, we see one passing example:

\n\n

User\n  is valid with an email, password, nickname, and API token\n  requires a nickname (PENDING: Not yet implemented)\n  requires a unique nickname (PENDING: Not yet implemented)\n  requires an email (PENDING: Not yet implemented)\n  requires a unique email (PENDING: Not yet implemented)\n  requires a password (PENDING: Not yet implemented)\n  requires an API token (PENDING: Not yet implemented)\n  sets a new user's API token (PENDING: Not yet implemented)\n\nPending: (Failures listed here are expected and do not affect your suite's status)\n\n  1) User requires a nickname\n    # Not yet implemented\n    # ./spec/models/user_spec.rb:15\n\n  2) User requires a unique nickname\n    # Not yet implemented\n    # ./spec/models/user_spec.rb:16\n\n  3) User requires an email\n    # Not yet implemented\n    # ./spec/models/user_spec.rb:17\n\n  4) User requires a unique email\n    # Not yet implemented\n    # ./spec/models/user_spec.rb:18\n\n  5) User requires a password\n    # Not yet implemented\n    # ./spec/models/user_spec.rb:19\n\n  6) User requires an API token\n    # Not yet implemented\n    # ./spec/models/user_spec.rb:20\n\n  7) User sets a new user's API token\n    # Not yet implemented\n    # ./spec/models/user_spec.rb:21\n\n\nFinished in 0.02298 seconds (files took 0.56166 seconds to load)\n8 examples, 0 failures, 7 pending\n

\n\n\n\n

Congratulations, you’ve written your first test!

\n\n

Matchers are key components in RSpec, so let’s take a moment to break down what be_valid implies. We could have written the test as

\n\n

expect(user.valid?).to eq true\n

\n\n\n\n

\n\n

expect(user.valid?).to be true\n

\n\n\n\n

In these variations, eq and be are also matchers. Matchers help make tests read like plain English, rather than the assert-style language you might have seen in other frameworks. be_valid has something else happening–before comparing the left side of the matcher to the right, it also calls the valid? method on the user under test. That’s why we don’t need to explicitly call user.valid? in the original test.

\n\n

RSpec includes many built-in matchers; we’ll explore some of them throughout the book. But for now, let’s write some more tests!

\n\n

\nTesting validations

\n\n

Validations are great for getting comfortable with automated testing. These tests can usually be written in just a few lines of code. Let’s fill in our nickname validation spec:

\n\n

spec/models/user_spec.rb

1 it \"requires a nickname\" do\n2   user = User.new(nickname: nil)\n3 \n4   expect(user).to be_invalid\n5 end\n

\n\n\n\n

This time, we expect that a new user with the nickname attribute explicitly set nil will not be valid. In this case, the be_invalid matcher calls user.invalid? before comparing the expected and actual values.

\n\n

That’s great, but the test doesn’t tell the ready why. Let’s fix that:

\n\n

spec/models/user_spec.rb

1 it \"requires a nickname\" do\n2   user = User.new(nickname: nil)\n3 \n4   expect(user).to be_invalid\n5   expect(user.errors[:nickname]).to include(\"can't be blank\")\n6 end\n

\n\n\n\n

Now, the test clarifies the reason the user isn’t valid, by ensuring the error message matches what we’d expect from this validation. We check for this using RSpec’s include matcher, which checks to see if a value is contained within an enumerable value (here, errors). And when we run RSpec again, we should be up to two passing specs.

\n\n

There’s a small problem in our approach so far. We’ve got a couple of passing tests, but we never saw them fail. This can be a warning sign, especially when starting out. We need to be certain that the test code is doing what it’s intended to do, also known as exercising the code under test.

\n\n

There are a couple of things we can do to prove that we’re not getting false positives. First, let’s flip that expectation by changing to to to_not:

\n\n

spec/models/user_spec.rb

1 it \"requires a nickname\" do\n2   user = User.new(nickname: nil)\n3 \n4   expect(user).to be_invalid\n5   expect(user.errors[:nickname]).to_not include(\"can't be blank\")\n6 end\n

\n\n\n\n

And sure enough, RSpec reports a failure:

\n\n

Failures:\n\n  1) User requires a nickname\n    Failure/Error: expect(user.errors[:nickname]).to_not include(\"can't be blank\")\n      expected [\"can't be blank\"] not to include \"can't be blank\"\n    # ./spec/models/user_spec.rb:19:in `block (2 levels) in <top (required)>'\n\nFinished in 0.02385 seconds (files took 0.55168 seconds to load)\n8 examples, 1 failure, 6 pending\n\nFailed examples:\n\nrspec ./spec/models/user_spec.rb:15 # User requires a nickname\n

\n\n\n\n\n\n

We can also modify the application code, to see how it affects the test. Undo the change we just made to the test (switch to_not back to to), then open the User model and temporarily comment out the nickname validation:

\n\n

app/models/user.rb

 1 require \"open-uri\"\n 2 \n 3 class User < ApplicationRecord\n 4   include Clearance::User\n 5 \n 6   has_many :recipes, dependent: :destroy\n 7   has_many :favorites, dependent: :destroy\n 8   has_many :favorite_recipes, through: :favorites, source: :recipe\n 9   has_many :comments, dependent: :destroy\n10   has_one_attached :avatar\n11 \n12   # validates :nickname, presence: true, uniqueness: true\n13   validates :api_token, presence: true, uniqueness: true\n14 \n15   before_validation :set_api_token, on: :create\n16   before_create :set_avatar\n17 \n18   # remainder of file omitted ...\n

\n\n\n\n

Run the specs again. This time, you should again see a failure. We told RSpec that a user with no nickname should be invalid, but our application code didn’t support that.

\n\n

These are easy ways to verify your tests are working as expected, especially as you progress from testing simple validations to more complex logic, and are testing code that’s already been written. If you don’t see a change in test output, then there’s a good chance that the test is not actually interacting with the code, or that the code behaves differently than you expect.

\n\n

Now we can use the same approach to test the :email validation.

\n\n

spec/models/user_spec.rb

1 it \"requires an email\" do\n2   user = User.new(email: nil)\n3 \n4   expect(user).to be_invalid\n5   expect(user.errors[:email]).to include(\"can't be blank\")\n6 end\n

\n\n\n\n

You may be thinking that these tests are relatively pointless–how hard is it to make sure validations are included in a model? The truth is, they can be easier to omit than you might imagine. More importantly, though, if you think about what validations your model should have while writing tests (ideally, and eventually, in a Test-Driven Development style of coding), you are more likely to remember to include them.

\n\n

Let’s build on our knowledge so far to write a slightly more complicated test–this time, to check the uniqueness validation on the nickname attribute:

\n\n

spec/models/user_spec.rb

 1 it \"requires a unique nickname\" do\n 2   User.create(\n 3     nickname: \"test\",\n 4     email: \"test1@example.com\",\n 5     password: \"password\"\n 6   )\n 7 \n 8   user = User.new(\n 9     nickname: \"test\"\n10   )\n11 \n12   expect(user).to be_invalid\n13   expect(user.errors[:nickname]).to include(\"has already been taken\")\n14 end\n

\n\n\n\n

Notice a subtle difference here: In this case, we first persisted a user (calling create on User instead of new) to build our test data, then instantiated a second user as the subject of the actual test. This, of course, requires that the first, persisted user is valid (with a nickname, email, and password) and has the same email address assigned to it. In chapter 4, we’ll look at utilities to streamline this process. In the meantime, run bin/rspec to see the new test’s output.

\n\n

Now let’s test a more complex validation. To do so, we’ll set aside tests for the User model, and turn to the Recipe model.

\n\n

Say we want to make sure that users can’t give two of their recipes the same name–the name should be unique within the scope of that user. In other words, I can’t have two recipes named Vegetable Stir Fry, but you and I could each have our own project named Vegetable Stir Fry. How might you test that?

\n\n

As we did for users, we’ll start by creating a new spec file for the Recipe model:

\n\n

$ bin/rails g rspec:model recipe\n

\n\n\n\n

Next, add two examples to the new file. We’ll test that a single user can’t have two recipes with the same name, but two different users can each have a recipe with the same name.

\n\n

spec/models/recipe_spec.rb

 1 require 'rails_helper'\n 2 \n 3 RSpec.describe Recipe, type: :model do\n 4   it \"does not allow duplicate recipe names per user\" do\n 5     user = User.create(\n 6       nickname: \"test-user\",\n 7       email:      \"test-user@example.com\",\n 8       password:   \"password\"\n 9     )\n10 \n11     category = Category.create(name: \"Test Category\")\n12 \n13     user.recipes.create(\n14       name: \"Test Recipe\",\n15       category: category\n16     )\n17 \n18     second_recipe = user.recipes.build(\n19       name: \"Test Recipe\",\n20     )\n21 \n22     expect(second_recipe).to_not be_valid\n23     expect(second_recipe.errors[:name]).to include(\"has already been taken\")\n24   end\n25 \n26   it \"allows two users to share a project name\" do\n27     user = User.create(\n28       nickname: \"test-user\",\n29       email:      \"test-user@example.com\",\n30       password:   \"password\"\n31     )\n32 \n33     other_user = User.create(\n34       nickname: \"another-test-user\",\n35       email:      \"another-test-user@example.com\",\n36       password:   \"password\"\n37     )\n38 \n39     category = Category.create(name: \"Test Category\")\n40 \n41     user.recipes.create(\n42       name: \"Test Recipe\",\n43       category: category\n44     )\n45 \n46     second_recipe = other_user.recipes.build(\n47       name: \"Test Recipe\",\n48       category: category\n49     )\n50 \n51     expect(second_recipe).to be_valid\n52   end\n53 end\n

\n\n\n\n

This time, since the User and Recipe models are coupled via an Active Record relationship, as are the Recipe and Category models, we need to provide a little extra information. In the case of the first example, we’ve got a user to which both recipes are assigned. In the second, the same project name is assigned to two unique recipes, belonging to unique users. Note that, in both examples, we have to create the users, or persist them in the database, in order to assign them to the projects we’re testing. And though it’s not part of what we’re testing here, in order to fulfill the app’s requirement that each recipe belong to a category, we also need to create a category in each of the tests.

\n\n

Since the Recipe model has the following validation:

\n\n

app/models/recipe.rb

validates :name, presence: true, uniqueness: { scope: :user_id }\n

\n\n\n\n

These new specs will pass without issue. Don’t forget to check your work–try temporarily commenting out the validation, or changing the tests so they expect something different. Do they fail now?

\n\n

Of course, validations can be more complicated than just requiring a specific scope. Yours might involve a complex regular expression, or a custom validator. Get in the habit of testing these validations–not just the happy paths where everything is valid, but also error conditions. For instance, in the examples we’ve created so far, we tested what happens when an object is initialized with nil values. If you have a validation to ensure that an attribute must be a number, try sending it a string. If your validation requires a string to be four-to-eight characters long, try sending it three characters, and nine.

\n\n

\nTesting instance methods

\n\n

Let’s resume testing the User model now. We’ve got the beginnings of a feature to treat new users differently than users who’ve been around for a little while. Perhaps someday, we might limit the number of recipes or comments a new user can post. For now, we’re just displaying a badge when attributing a recipe to a new user.

\n\n

To handle this, we’ve got this method in the User class:

\n\n

app/models/user.rb

def new_to_site?\n  created_at > 1.month.ago\nend\n

\n\n\n\n

We can use the same basic techniques we used for our validation examples to create a passing example of this feature:

\n\n

spec/models/user_spec.rb

1 it \"indicates a new user\" do\n2   user = User.new(created_at: Time.now)\n3 \n4   expect(user.new_to_site?).to be true\n5 end\n

\n\n\n\n

Cool, but what about a user who’s been here for awhile? We should test that, too:

\n\n

spec/models/user_spec.rb

1 it \"indicates an established user\" do\n2   user = User.new(created_at: 1.month.ago)\n3 \n4   expect(user.new_to_site?).to be false\n5 end\n

\n\n\n\n

Not too bad, but let’s tidy these tests up with some matcher magic. Remember earlier in this chapter that we used be_valid and be_invalid as matchers for testing a User object’s validity? We can use be_ on our own methods that return booleans, too!

\n\n

spec/models/user_spec.rb

 1 it \"indicates a new user\" do\n 2   user = User.new(created_at: Time.now)\n 3 \n 4   expect(user).to be_new_to_site\n 5 end\n 6 \n 7 it \"indicates an established user\" do\n 8   user = User.new(created_at: 1.month.ago)\n 9 \n10   expect(user).to_not be_new_to_site\n11 end\n

\n\n\n\n

Personally, I love this feature of RSpec. I think it makes tests read more like documentation and less like code. If you or your team disagree, there’s nothing wrong with the previous iterations of these tests.

\n\n

Either way, we’re establishing a pattern for testing: Create test data, then tell RSpec how you expect it to behave. Let’s keep going.

\n\n

\nTesting class methods and scopes

\n\n

Our users can search recipe titles for a provided term. For the sake of demonstration, it’s currently implemented as a scope on the Recipe model:

\n\n

app/models/recipe.rb

1 scope :by_word_in_name, ->(query) {\n2   where(\"name LIKE ?\", \"%#{query}%\") if query.present?\n3 }\n

\n\n\n\n

Let’s add another test to recipe_spec to cover this:

\n\n

spec/models/recipe_spec.rb

 1 it \"finds recipes that contain the search term in their name\" do\n 2   user = User.create(\n 3     nickname: \"test-user\",\n 4     email: \"test-user@example.com\",\n 5     password: \"password\"\n 6   )\n 7 \n 8   category = Category.create(name: \"Test Category\")\n 9 \n10   first_recipe = user.recipes.create(\n11     name: \"Pepperoni Pizza\",\n12     category: category\n13   )\n14 \n15   second_recipe = user.recipes.create(\n16     name: \"Cheese Pizza\",\n17     category: category\n18   )\n19 \n20   results = Recipe.by_word_in_name(\"pepperoni\")\n21 \n22   expect(results).to include(first_recipe)\n23   expect(results).to_not include(second_recipe)\n24 end\n

\n\n\n\n

The by_word_in_name scope should return a collection of recipes matching the search term, and that collection should only include those recipes–not ones that don’t contain the term.

\n\n

This test gives us some other things to experiment with: What happens if we flip around the to and to_not variations on the tests? Or add more recipes containing the search term?

\n\n

\nTesting all the cases

\n\n

We’ve tested the happy path–a user searches a term for which we can return results–but what about occasions when the search returns no results? We’d better test that, too. The following spec should do it:

\n\n

spec/models/recipe_spec.rb

 1 it \"returns an empty collection when no recipes matching the search term are foun\\\n 2 d\" do\n 3   user = User.create(\n 4     nickname: \"test-user\",\n 5     email: \"test-user@example.com\",\n 6     password: \"password\"\n 7   )\n 8 \n 9   category = Category.create(name: \"Test Category\")\n10 \n11   first_recipe = user.recipes.create(\n12     name: \"Pepperoni Pizza\",\n13     category: category\n14   )\n15 \n16   second_recipe = user.recipes.create(\n17     name: \"Cheese Pizza\",\n18     category: category\n19   )\n20 \n21   results = Recipe.by_word_in_name(\"veggie\")\n22 \n23   expect(results).to be_empty\n24 end\n

\n\n\n\n

This spec checks the value returned by Recipe.by_word_in_name(\"veggie\"). Since the resulting collection is empty, the spec passes! We’re testing not just for the ideal results, but also for searches with no results.

\n\n

\nMore about matchers

\n\n

We’ve already seen four matchers in action: be_valid, eq, include, and be_empty. First we used be_valid, which is provided by the rspec-rails gem to test a Rails model’s validity. eq and include come from rspec-expectations, installed alongside rspec-rails when we set up our app to use RSpec in the previous chapter.

\n\n

A complete list of RSpec’s default matchers may be found in the README for the rspec-expectations repository on GitHub. We’ll look at several of these throughout this book. In chapter 8, we’ll take a look at creating custom matchers of our own.

\n\n

\nSummary

\n\n

This chapter focused on testing models, but we’ve covered a lot of other important techniques you’ll want to use in other types of specs moving forward:

\n\n

\nUse active, explicit expectations: Use verbs to explain what an example’s results should be. Try to only check for one result per example. (We’ll talk about exceptions to this in a later chapter.)
\nTest for what you expect to happen, and for what you expect to not happen: Think about both paths when writing examples, and test accordingly.
\nTest for edge cases: If you have a validation that requires a password be between four and ten characters in length, don’t just test an eight-character password and call it good. A good set of tests would test at four and ten, as well as at three and eleven. (Of course, you might also take the opportunity to ask yourself why you’d allow such short passwords, or not allow longer ones. Testing is also a good opportunity to reflect on an application’s requirements and code.)

\n\n

With a solid collection of model specs incorporated into your app, you’re well on your way to more trustworthy code. Great work!

\n\n

\nExercises

\n\n

If you’re following along with your own, untested Rails code, take a look at its models now. What attributes map to their underlying database tables? How are data validated? What other business logic do they contain?

\n\n

These are all great candidates for your first test coverage. Start by generating a model spec for a given model, then outline the scenarios you want to test. Think through how to build just enough test data for each scenario, and how it would prove that your code behaves as you want. Then write each spec and run. I recommend doing this one test at a time. Don’t worry if you’re repeating yourself from test to test. We’ll explore de-duplication options in the next chapter.

\n\n

As you’re writing and running you new specs, do you notice anything unexpected about your application code? Like, a feature that doesn’t quite work as you’d assumed it did, or code that would benefit from refactoring? Congratulations! You’re already seeing the benefits of test-driven software design!

\n\n\n

\nAbout Everyday Rails

\n\n

Everyday Rails is a blog about using the Ruby on Rails web application framework to get stuff done as a web developer. It’s about finding the best tools and techniques to get the most from Rails and help you get your apps to production. Visit Everyday Rails at https://everydayrails.com/.

\n\n

\nAbout the author

\n\n

Aaron Sumner is a software engineer with nearly 35 years working professionally, developing web applications in the education and publishing industries. Since 2005, he has worked primarily in Ruby on Rails, though in his day job as an Engineering Manager at O’Reilly Media, spends time in Python and Go. He enjoys helping small development teams achieve ambitious goals through the pragmatic use of technology.

\n\n

Aaron resides in Saint Louis, Missouri, with his wife, Caitlin, and dog, Lieutenant Dan. Away from work he enjoys woodworking and being outside.

\n\n

Visit Aaron’s personal site at https://aaronsumner.com/.

\n\n\n

\nColophon

\n\n

The original cover image “Old truck in early morning light stock photo”\nis by iStockphoto contributor Habman_18.

\n\n

\n\n","tocStructure",[215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249],{"_77":78,"_44":79,"_71":-5,"_80":81,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":78,"_44":87,"_71":-5,"_80":88,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":92,"_71":-5,"_80":93,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":97,"_71":-5,"_80":98,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":100,"_71":-5,"_80":101,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":103,"_71":-5,"_80":104,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":106,"_71":-5,"_80":107,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":109,"_71":-5,"_80":110,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":112,"_71":-5,"_80":113,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":115,"_71":-5,"_80":116,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":118,"_71":-5,"_80":119,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":121,"_71":-5,"_80":122,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":124,"_71":-5,"_80":125,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":78,"_44":127,"_71":-5,"_80":128,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":131,"_71":-5,"_80":132,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":134,"_71":-5,"_80":135,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":137,"_71":-5,"_80":138,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":140,"_71":-5,"_80":141,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":143,"_71":-5,"_80":144,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":146,"_71":-5,"_80":147,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":149,"_71":-5,"_80":150,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":78,"_44":152,"_71":-5,"_80":153,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":156,"_71":-5,"_80":157,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":159,"_71":-5,"_80":160,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":162,"_71":-5,"_80":163,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":165,"_71":-5,"_80":166,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":168,"_71":-5,"_80":169,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":171,"_71":-5,"_80":172,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":174,"_71":-5,"_80":175,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":177,"_71":-5,"_80":178,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":146,"_71":-5,"_80":180,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":91,"_44":149,"_71":-5,"_80":182,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":78,"_44":184,"_71":-5,"_80":185,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":78,"_44":188,"_71":-5,"_80":189,"_73":82,"_94":-5,"_95":-5,"_85":-5},{"_77":78,"_44":192,"_71":-5,"_80":193,"_73":82,"_94":-5,"_95":-5,"_85":-5},"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]

\nColophon

Table of Contents

\nPreface to this edition

\n1. Introduction

\nConfident testing

\nWhy RSpec?

\nWho should read this book

\nMy testing philosophy

\nHow the book is organized

\nDownloading the sample code

\nCode conventions

\nDiscussion and errata

\nA note about gem versions

\nA note about styling

\nAbout the sample application

\n2. Setting up RSpec

\nDependencies

\nTest database

\nRSpec configuration

\nThe rspec binstub

\nTry it out!

\nSummary

\nExercises

\n3. Model specs

\nAnatomy of a model spec

\nCreating a model spec

\nThe RSpec syntax

\nTesting validations

\nTesting instance methods

\nTesting class methods and scopes

\nTesting all the cases

\nMore about matchers

\nSummary

\nExercises

\nAbout Everyday Rails

\nAbout the author

\nColophon

\nThe `rspec` binstub