One of the most common questions asked by Rails developers new to testing is: how do I make testing a habitual part of my development work?

It’s one thing to know how to write tests. It’s another thing to actually write tests consistently as a normal part of your work.

In order to share with you how to make testing a habitual part of your development work, I conducted a poll among some of my peers in the Rails world to see what keeps them in the habit of writing tests consistently. I also examined my own motivations.

When I drew the commonalities among the answers, what I came up with was a trifecta not unlike Larry Wall’s three virtues of a great programmer. The trifecta is laziness, fear, and pride. Let’s examine each “virtue” individually.

Laziness

It might sound funny to name laziness as the first motivation for writing tests habitually. After all, tests seem like extra work. Writing tests consistently seems like something that would require discipline. But for me and many of the people who responded to my poll, it’s quite the opposite.

The alternative to automated tests

The alternative to writing tests isn’t just doing nothing. The alternative to writing tests is to perform manual testing, to let your users test your application for you in production, or most likely, a combination of the two. The alternative to writing tests is to suffer great pain and toil.

The laziness factor also extends beyond QA. I personally find that the process of writing features is often easier and more pleasant when I’m writing with the assistance of tests than when I’m not.

Mental energy

Mental energy is a finite, precious resource that (for me at least) starts full in the morning and depletes throughout the day. When I’m working I don’t ever want to use more than the minimum amount of mental exertion necessary to complete a task.

If I write a feature without using tests, I’m often juggling the “deciding what to do” work and the “actually doing it” work at the same time, which has a cognitive cost more than twice as much as performing those two jobs separately in serial. When I build a feature with the aid of tests, the tests allow me to separate the “deciding what to do” work from the “actually doing it” work.

It works like this. First I capture what to do in the form of a test. Then I follow my own instructions by getting the test to pass. Then I repeat. This is a much lighter cognitive burden than if I were to juggle these different mental jobs and allows me to be productive for longer because I don’t run out of mental energy as early in the day.

Code understandability

It’s more difficult, time-consuming and unpleasant to work with messy code than to work with clear and tidy code.

Being a lazy person, difficult, time-consuming and unpleasant work is exactly what I don’t want to do. I want to do work that’s pleasant, quick and easy.

Unfortunately it’s not possible to have clean, understandable code without having automated tests. This might sound like a hyperbolic claim but it’s not. I can prove it based on a chain of truths.

The first truth is that it’s impossible to write a piece of code cleanly on the first try. Some amount of refactoring, typically a lot of refactoring, is necessary in order to get the code into a reasonably good state. This is true on a feature-by-feature basis but it’s especially true on the scale of a whole project codebase.

The second truth is that it’s impossible to do non-trivial refactorings without having automated tests. The feedback cycle is just too long when all the testing is done manually. Either that or the risk of refactoring without testing afterward is just too large to be justified.

So, if it’s impossible to have good code without refactoring, and it’s impossible to do refactoring without tests, then it’s impossible to have good code without tests.

My extreme personal laziness demands that I only write neat and understandable code. Therefore, I have to write tests in order to satisfy my laziness.

Fear

Fear is another powerful impetus for testing. If I don’t write tests for my features, it increases the risk that I release a bug to production. Bugs cause me shame and embarrassment. I don’t want to feel embarrassment or shame.

Bugs may also have negative business consequences to the company I work for. This could negatively affect the company’s ability or willingness to pay me as much as I want.

When laziness doesn’t drive me to write tests, fear often does.

Pride

Lastly there’s pride. (I find Larry Wall’s “hubris” a little too strong a word.)

Sometimes, when I’m tempted not to write a test for a feature, I imagine another developer stumbling across my work in the future and seeing that there are no tests. I imagine myself sheepishly admitting to that developer that I didn’t bother to write tests for that feature. Why didn’t I write tests? No good reason.

As the arrogant person that I am, this imaginary interaction brings me pain. I really don’t like the idea that somebody else would look at my work and make a (legitimate) negative judgment.

I also want my work to be exemplary. If we hire a junior developer where I work, I want to be able to point to my code and say “This is how we do it.” I don’t know how I would explain that my test coverage is poor but I want theirs to be good.

Takeaways

I’m not driven to write tests out of discipline. I also don’t consider testing to be “extra” effort but rather an effort-saver.

The main forces that drive me to write tests are laziness, fear and pride. Mostly laziness.

Why testers often suffer from “writer’s block”

When you write a test, you’re carrying out two jobs:

1. Deciding what steps the test should carry out
2. Translating those steps into code

For trivial tests, these two steps are easy enough that both can be done together, and without conscious thought. For non-trivial tests (especially tests that include complex setup steps), doing both these steps at once is too much mental juggling for a feeble human brain, or at least my feeble human brain.

This is when testers experience “writer’s block”.

Luckily, there’s a way out. When the implementation of a test eludes me, I consciously separate the job into the two steps listed above and I tackle each one at a time.

How to overcome writer’s block

Let’s say, for example, that I want to write an integration test that tests a checkout process. Maybe I can’t think of all the code and setup steps that are necessary to carry out this test. I probably can, however, think of the steps I would take just as a regular human being manually testing the feature in a web browser. So, in my test file, I might write something like this:

scenario 'create order' do
  # create a product
  # visit the page for that product
  # add that product to my cart
  # visit my cart
  # put in my credit card details, etc.
  # click the purchase button
  # expect the page to have a success message
end

Now I have all the high-level steps listed out. I can tell my brain that it’s relieved of the duty of trying to hold all the test steps in memory. Now my brain’s capacity is freed up to do other jobs. The next job I’ll give it is translating the steps into code.

I’ll start with the first line.

scenario 'create order' do
  electric_dog_polisher = create(:product)
  # visit the page for that product
  # add that product to my cart
  # visit my cart
  # put in my credit card details, etc.
  # click the purchase button
  # expect the page to have a success message
end

That was easy enough. Now I’ll move onto the next line.

scenario 'create order' do
  electric_dog_polisher = create(:product)
  visit product_path(electric_dog_polisher)
  # add that product to my cart
  # visit my cart
  # put in my credit card details, etc.
  # click the purchase button
  # expect the page to have a success message
end

And I’ll go down the comments, line by line, translating each line into Ruby code.

Not every step will be trivially easy. But at the same time, it’s unlikely that any individual line is all that hard. What’s hard is trying to solve 26 different problems at once in your head. The way to make progress is to break those problems down into tiny parts, get those parts out of your head and onto the screen, and then tackle the tiny parts one at a time.

Many Rails developers who are new to writing tests struggle with the question of what to write tests for and how.

I’m about to share with you a repeatable formula that you can use to write an integration test for almost any Rails feature. It’s nothing particularly profound, it won’t result in 100% test coverage, and it won’t work in all cases, but it will certainly get you started if you’re stuck.

The three integration test cases I write for any Rails CRUD feature

Most features in most Rails applications are, for better or worse, some slight variation on CRUD operations. Here are the tests I almost always write for every CRUD feature.

1. Creating a record with valid inputs
2. Trying to create a record with invalid inputs
3. Updating a record

Let me go into detail on each one of these. For each test case, let’s imagine we’re working with a resource called Location.

Creating a record with valid inputs

This test case will involve the following steps:

1. If necessary, sign a user in (using login_as(create(:user)) as I describe in this post)
2. Visit the “new” route for the resource (e.g. visit new_location_path)
3. Fill out the form fields using fill_in, select, etc.
4. Click the “submit” button
5. Expect that the page has whatever content the resource’s index page has, e.g. expect(page).to have_content('Locations')

Here’s what that test might look like:

require 'rails_helper'

RSpec.describe 'Creating a location', type: :system do
  before do
    login_as(create(:user))
    create(:state, name: 'Michigan')
    visit new_location_path
  end

  scenario 'valid inputs' do
    fill_in 'Name', with: "Jason's House"
    fill_in 'Line 1', with: '69420 Cool Ave'
    fill_in 'City', with: 'Sand Lake'
    select 'Michigan', from: 'State'
    fill_in 'Zip code', with: '49343'
    click_on 'Save Location'

    expect(page).to have_content('Locations')
  end
end

Trying to create a record with invalid inputs

This test is pretty simple because all I have to do is not fill out the form. So the steps are:

1. If necessary, sign a user in (using login_as(create(:user))
2. Visit the “new” route for the resource (e.g. visit new_location_path)
3. Click the “submit” button
4. Expect that the page shows an error (e.g. expect(page).to have_content("Name can't be blank"))

Here’s what a test of this type might look like.

require 'rails_helper'

RSpec.describe 'Creating a location', type: :system do
  before do
    login_as(create(:user))
    create(:state, name: 'Michigan')
    visit new_location_path
  end

  scenario 'invalid inputs' do
    click_on 'Save Location'
    expect(page).to have_content("Name can't be blank")
  end
end

Updating a record

The steps for this one go:

1. If necessary, sign a user in (using login_as(create(:user))
2. Create an instance of the resource I’m testing (e.g. location = create(:location))
3. Visit the “edit” route for the resource (e.g. visit edit_location_path(location))
4. Fill in just one field with a different value
5. Click the “submit” button
6. Expect that the page has whatever content the resource’s index page has, e.g. expect(page).to have_content('Locations')

require 'rails_helper'

RSpec.describe 'Updating a location', type: :system do
  before do
    login_as(create(:user))
    location = create(:location)
    visit edit_location_path(location)
  end

  scenario 'valid inputs' do
    fill_in 'Name', with: "Jason's Filthy Shack"
    click_on 'Save Location'
    expect(page).to have_content('Locations')
  end
end

“But is that enough? Don’t I need more?”

No, this is not “enough”, and yes, you do need more…eventually. What I’m hoping to share with you here is a base that you can start with if you’re totally lost. Writing halfway-good tests is better than writing no tests, and even writing crappy tests is better than writing no tests. Once you get some practice following the formula above, you can expand on that formula to get a better level of test coverage.

Where to go next

If you get some practice with writing tests like the above and you want to go further, you might like my RSpec/Capybara integration test tutorial.