Test My Rails App Before Launch: What to Cover and How

Testing a Rails app before launch means covering three layers Rails names for you: model tests for business rules and validations, request tests for each endpoint and its authorisation, and system tests that drive a real browser through the journeys that matter. Use Minitest or RSpec against a test database, money and data paths first. An outside team can do this whether or not they built the app.

If you would rather have the suite built and run for you, see how RAITHub would test this near the end. RAITHub tests apps in these stacks; testing a framework does not require having built in it.

What should a Rails test suite cover?

Rails ships with testing built in and names the layers, so the plan is clear. Models hold validations and business logic; requests exercise your controllers and the authorisation on each action; system tests drive a real browser. The Rails guide groups tests exactly this way, model, controller/request and system (Rails Testing Guide), and the permission layer is where the costly bugs hide.

Layer	What to test	Typical tool
Model specs	Validations, scopes, business methods, callbacks, database constraints	Minitest or RSpec
Request specs	Status, response, each action's authentication and authorisation per role	Minitest / RSpec request tests
Job and mailer tests	Background jobs enqueue and run; mailers send the right content	Active Job / Action Mailer test helpers
System specs	Sign-in, the core workflow, checkout, in a real browser	Capybara with a headless driver, or Playwright

Most of the protection comes from model and request specs, which run fast. A small system-spec set proves the whole thing holds together; that shape is the test pyramid, in the test pyramid for a SaaS.

What tools fit a Rails app?

Rails includes Minitest and a full testing setup out of the box, including system tests driven through Capybara (Rails Testing Guide). Many teams prefer RSpec for its readable syntax; either is a fine choice, and the layers you test matter more than the framework. Rails runs tests against a separate test database and resets it between tests, so your real data is never touched.

For the browser journeys, Capybara with a headless Chrome driver is the Rails default. A team that also wants cross-browser coverage can drive the same journeys with Playwright; the cross-browser testing checklist covers what that pass should include. Whatever the tools, the specs belong in your repository and run in CI on every pull request; continuous testing in CI/CD covers how to wire it in.

What does a good Rails request spec look like?

Drive the controller action over HTTP as a signed-in user, and check both that the right user succeeds and that the wrong user is refused. The second half is the test that stops one user reading another's record. This request spec checks the authorisation rule:

# spec/requests/orders_spec.rb
require "rails_helper"

RSpec.describe "Orders", type: :request do
  it "does not let a user read another user's order" do
    alice = create(:user)
    bob = create(:user)
    order = create(:order, user: alice)

    sign_in bob
    get "/orders/#{order.id}"

    expect(response).to have_http_status(:not_found).or have_http_status(:forbidden)
  end
end

Write that kind of spec for every controller action and role. Each spec creates its own data and runs inside a transaction that rolls back afterwards, so the specs stay independent. For the full endpoint checklist, status, validation, authentication, idempotency and errors, see the API testing guide.

Fixtures or factories, and real database or mocks?

Both approaches to test data work: Rails fixtures are fast and load once, while factories (FactoryBot) build objects per test and read more clearly for complex cases. Pick one per project and stay consistent. On the bigger question, hit a real test database rather than mocking it: mocking hides the wrong-query and unenforced-constraint bugs that specs exist to catch. Stub only external services, payments, email and SMS, at the boundary and test those in sandbox mode.

Choice	Fixtures	Factories (FactoryBot)
Speed	Fast, loaded once	Slower, built per test
Readability for complex cases	Harder	Clearer
Risk of shared, surprising state	Higher	Lower

Buy, build or hire?

Option	Choose this when	Watch out for
A tool or SaaS testing platform	You want recorded browser checks fast, with little code	Recorded tests break often and live outside your repository
Freelancers or crowdtesting	You need a one-off manual pass before a launch	No suite remains, and no one maintains it
An in-house QA hire	You release weekly and want QA on the team long-term	Needs someone who writes Ruby, not only a manual tester
A managed QAaaS team	You want the suite built across layers, gated in CI and kept current	Make sure the specs live in your repository and you own them

Why RAITHub for testing a Rails app?

RAITHub tests apps in these stacks whether or not it built them, and the QA method does not change with the framework: map the risk, test the money and data paths at the lowest layer that catches them, write the authorisation specs that stop data leaks, and gate the suite in CI. The test counts come from real repositories, 400+ on this site, 530+ on Sundor Skin across 88 permission codes and 12 roles, 1,024 on PropDesk; how that discipline works is in QA-first development: how RAITHub tests.

When you don't need RAITHub: if you want an engineer placed inside your team under your management, that is staff augmentation, which RAITHub does not offer; and a prototype you reshape weekly may only need a short manual pass. For a framework RAITHub builds in natively, see testing a Node/Express API, which shares the same method.

How RAITHub would test this

Through QA and test automation, part of QA as a service, RAITHub would:

• map your models, controllers and roles, and rank the money and data paths by cost of failure
• write model specs for validations and business rules, and request specs with an authorisation matrix per role
• cover background jobs and mailers, and add a small system-spec set for the journeys that matter
• wire the suite into your CI so a failing change blocks the release, with specs and configuration in your repository

Buy it as a monthly QA plan, a fixed-price one-off audit, or a dedicated QA team that RAITHub manages and bills monthly. Testers are never placed under your management. You own the specs and the IP, and an NDA is signed first. Start with a free 15-minute call, then a written fixed quote. Talk to RAITHub about testing your Rails app.

Frequently asked questions

How do I test a Rails app before launch?

Write model specs for validations and business rules, request specs for each action's authentication and authorisation per role, cover jobs and mailers, and add a small system-spec set for the journeys that matter, all against a test database and running in CI.

Should I use Minitest or RSpec?

Either. Rails ships with Minitest and a full testing setup; many teams prefer RSpec for its readable syntax. The layers you cover matter far more than the framework you pick; choose one and stay consistent.

What is a system spec in Rails?

A system spec drives a real browser through a whole journey, using Capybara with a headless driver. It is the Rails equivalent of an end-to-end test and should be kept to the few journeys that earn money or hold data.

Should I use fixtures or factories?

Both work. Fixtures are fast and load once; factories build objects per test and read more clearly for complex cases. Pick one approach per project and stay consistent so the suite is predictable.

Can RAITHub test a Rails app it did not build?

Yes. Testing an app does not require having built it. RAITHub starts with the money and data paths, writes specs that pin down current behaviour, and gates them in CI before widening coverage or changing any code.

Will I own the specs?

Yes. The specs and CI configuration live in your repository, the IP is assigned to you, and the engagement runs month-to-month, so the suite keeps protecting you after it ends.