Snelle Rails Tests: Hoe Minitest en Fixtures je Testsuite Versnellen

Een Rails app met 3.000 tests hoort geen 20 minuten te duren. Als dat bij jou wel zo is, zijn factories waarschijnlijk de boosdoener.

Ik heb vorig kwartaal een productie Rails 8 app gemigreerd van FactoryBot naar fixtures. De volledige suite ging van 14 minuten naar 3 minuten en 40 seconden. Geen testlogica veranderd. Dezelfde assertions, dezelfde coverage. Het enige verschil was hoe testdata in de database terechtkwam.

Dit is wat ik heb geleerd, inclusief de delen die niet vanzelfsprekend waren.

Waarom Factories Traag Worden

FactoryBot (en vergelijkbare libraries) maken database records aan tijdens runtime. Elke create(:user) aanroep voert een INSERT statement uit. De meeste factories triggeren callbacks, die weer meer INSERTs veroorzaken. Een test die een gebruiker nodig heeft met een team, drie projecten en wat permissies kan 15+ database operaties uitvoeren voordat de eerste assertion draait.

Vermenigvuldig dat met 3.000 tests en je besteedt het grootste deel van je testtijd aan setup, niet aan verificatie.

Fixtures werken anders. Rails laadt fixture data eenmalig via een enkele bulk INSERT per tabel, wrapt elke test in een transactie en rolt terug na elke test. Geen per-test database writes voor setup. De data is er gewoon.

# FactoryBot aanpak — voert INSERTs uit bij elke test
test "user can publish a draft" do
  user = create(:user, role: :editor)
  post = create(:post, author: user, status: :draft)

  post.publish!

  assert post.published?
end

# Fixture aanpak — data al geladen, nul setup INSERTs
test "user can publish a draft" do
  post = posts(:draft_post)

  post.publish!

  assert post.published?
end

De fixture versie is niet alleen korter. Hij draait ongeveer 4x sneller omdat database setup volledig wordt overgeslagen.

Fixtures Opzetten Zonder Frustratie

De grootste klacht over fixtures is onderhoud. Mensen herinneren zich Rails 2-tijdperk YAML bestanden met 500 regels vol verstrengelde cross-references. Moderne fixtures in Rails 8 zijn aanzienlijk beter.

Bestandsstructuur

Elk model krijgt een YAML bestand in test/fixtures/:

# test/fixtures/users.yml
alice:
  name: Alice Chen
  email: alice@example.com
  role: editor
  team: engineering

bob:
  name: Bob Park
  email: bob@example.com
  role: viewer
  team: engineering

# test/fixtures/teams.yml
engineering:
  name: Engineering
  created_at: <%= 2.years.ago %>

Associatie-referenties gebruiken direct de fixture naam. Rails vertaalt author: alice automatisch naar de juiste foreign key.

ERB in fixtures

Fixtures ondersteunen ERB voor dynamische waarden:

recent_login:
  user: alice
  ip_address: 192.168.1.1
  created_at: <%= 30.minutes.ago %>
  session_token: <%= SecureRandom.hex(32) %>

Houd fixture bestanden gefocust

Maak alleen de records aan die je tests daadwerkelijk refereren. Je hebt geen 50 gebruikers nodig “voor het geval dat.” Begin met 5-8 records per model en voeg meer toe wanneer specifieke tests dat vereisen.

Migreren Van FactoryBot Naar Fixtures

FactoryBot in één keer uit een grote codebase trekken is pijnlijk en onnodig. Dit is de incrementele aanpak die voor mij werkte.

Stap 1: Maak fixtures van je meest gebruikte factories.

Bekijk welke factories het vaakst worden aangeroepen:

grep -r "create(:" test/ | sed 's/.*create(:\([a-z_]*\).*/\1/' | sort | uniq -c | sort -rn | head -10

Begin met de top 3-5. Schrijf fixture YAML bestanden die dezelfde datastructuren dekken.

Stap 2: Migreer één testbestand per keer.

Kies een testbestand. Vervang create(:thing) aanroepen door fixture referenties. Draai het bestand. Fix eventuele fouten. Commit.

Stap 3: Houd FactoryBot voor uitzonderingsgevallen.

Sommige tests hebben oprecht unieke datacombinaties nodig die geen eigen fixture rechtvaardigen. Dat is prima. Het doel is niet nul factories — het is de bulk van je data setup naar fixtures verplaatsen zodat het gangbare geval snel is.

Parallel Testing in Rails 8

Rails wordt geleverd met ingebouwde parallel testing. Gecombineerd met fixtures is dit waar de echte snelheidswinst zich opstapelt.

# test/test_helper.rb
class ActiveSupport::TestCase
  parallelize(workers: :number_of_processors)
  fixtures :all
end

Met parallelize maakt Rails aparte database instances voor elk worker proces en laadt fixtures in elk ervan. Tests draaien gelijktijdig over alle CPU cores.

Op een 6-core machine bracht dit alleen al de suite van 3:40 naar ongeveer 1:15. Gecombineerd met de fixture migratie gingen we van 14 minuten naar 75 seconden. Dat is een 11x versnelling.

Valkuilen bij parallellisatie

Gedeelde state: Tests die naar het bestandssysteem schrijven, met externe services communiceren of class-level mutable state gebruiken, breken onder parallelle executie.

Database volgorde: Ga niet uit van een bepaalde testvolgorde. Fixtures lossen dit grotendeels op — de data is er altijd.

Transactionele fixtures: Parallel testing met processen (de standaard) kan geen transactionele fixtures over workers heen gebruiken. Rails handelt dit automatisch af.

Minitest Patronen Die je Tests Versnellen

Naast data setup houden een paar Minitest gewoontes je suite snel.

Gebruik assert_changes en assert_difference

test "publishing increments the published count" do
  post = posts(:draft_post)

  assert_difference -> { Post.published.count }, 1 do
    post.publish!
  end
end

Vermijd setup blokken voor test-specifieke data

Als slechts één test in een bestand specifieke data nodig heeft, maak die dan inline aan in plaats van in setup. Elke regel in setup draait voor elke test in het bestand.

Profileer trage tests

rails test --verbose 2>&1 | grep "seconds" | sort -t= -k2 -rn | head -20

Of gebruik de minitest-reporters gem voor geformatteerde output inclusief timing per test.

Fixtures Met Has-Many-Through en Polymorphe Associaties

Het lastige deel van fixtures zijn complexe associaties.

Has-many-through (join tables)

# test/fixtures/project_memberships.yml
alice_on_main:
  user: alice
  project: main_project
  role: maintainer

Geef het join record een beschrijvende naam. alice_on_main is direct leesbaar.

Polymorphe associaties

# test/fixtures/comments.yml
comment_on_post:
  body: "Looks good to me"
  commentable_type: Post
  commentable_id: <%= ActiveRecord::FixtureSet.identify(:published_post) %>
  author: alice

STI (Single Table Inheritance)

# test/fixtures/notifications.yml
email_notification:
  type: EmailNotification
  recipient: alice
  subject: "Your post was published"

Stel de type kolom expliciet in. Rails instantieert de juiste subklasse.

Wanneer Factories Nog Zinvol Zijn

Fixtures zijn niet universeel beter. Gebruik factories wanneer:

• Unieke combinaties genereren: Een test die 100 gebruikers nodig heeft met gerandomiseerde attributen.
• Validatie edge cases testen: Wanneer je wilt testen dat ongeldige data errors gooit.
• Tijdelijke data: Records die alleen voor één test moeten bestaan.

De praktische verdeling waar ik op uitgekomen ben: fixtures voor de stabiele, veelgebruikte data die de meeste tests nodig hebben. Factories voor de uitzonderingen.

Benchmarks: Echte Cijfers Van een Productie App

De app: een Rails 8.0 projectmanagement tool. PostgreSQL 16, Ruby 3.3.

FAQ

Kan ik fixtures en FactoryBot in dezelfde testsuite gebruiken?

Ja. Beide werken prima naast elkaar. Laad fixtures globaal in test_helper.rb met fixtures :all, gebruik dan FactoryBot in specifieke tests waar je custom records nodig hebt.

Werken fixtures met database_cleaner?

Je hebt database_cleaner niet nodig met fixtures. Rails’ transactionele test wrapper handelt cleanup automatisch af — elke test draait in een transactie die teruggerold wordt.

Hoe ga ik om met fixtures voor modellen met complexe validaties of callbacks?

Fixture data omzeilt model validaties en callbacks tijdens het laden. Dit is opzettelijk — fixtures vertegenwoordigen bekende correcte database state. Als een model een password hash vereist, genereer die in de fixture met ERB: password_digest: <%= BCrypt::Password.create('password') %>.

Breekt parallel testing mijn system tests met Capybara?

System tests vereisen extra zorg. Elke parallelle worker heeft zijn eigen server poort nodig, en Capybara handelt dit automatisch af in Rails 8. Het belangrijkste risico is test pollution door gedeelde browser state — gebruik setup { Capybara.reset_sessions! } als je flaky system tests ziet.

Hoe voorkom ik dat fixture bestanden onbeheersbaar groeien?

Audit fixtures elk kwartaal. Verwijder elke fixture die geen enkele test referenteert. Een snelle check: grep -r "fixture_name" test/. Houd elk YAML bestand onder de 30 records.