DEV Community: Pavel Myslik

Testing Turbo Frames in Rails Without a Browser

Pavel Myslik — Wed, 27 May 2026 13:37:29 +0000

Turbo Frames are a great way to build interactive pages without writing custom JavaScript. But how do you test them properly?

You can reach for system tests with Capybara and a real browser, but for many Turbo Frame interactions, this can be unnecessary overkill.

Rails integration tests are faster and more stable, and the turbo-rails gem provides dedicated Minitest assertions for working with Turbo Frames that many Rails developers don't know about.

How a Turbo Frame Request Works

When the browser loads content into a <turbo-frame> element, it adds an HTTP header to the request:

Turbo-Frame: "frame_name"

turbo-rails detects this header and renders the response using a minimal layout optimized for Turbo Frame requests instead of the full application layout.

This is a rendering optimization, since Turbo extracts the matching <turbo-frame> element from the response in the browser and swaps it into the page. The rest of the page is already present and does not need to be rendered again.

Simulating a Turbo Frame Request in Tests

To simulate a Turbo Frame request in a controller test, just add the header:

get edit_article_path(article), headers: { "Turbo-Frame" => "article_1" }

Rails will treat the request as a Turbo Frame request and render the response accordingly, as it would when triggered from a <turbo-frame> in the browser.

Turbo Frame Test Helpers

The turbo-rails gem provides two main assertion helpers for testing <turbo-frame> elements in Rails integration tests.

assert_turbo_frame

Asserts that the response contains a <turbo-frame> element with the given attributes.

assert_turbo_frame "article_1"

Arguments:

ids — the frame's [id] attribute. Also accepts an ActiveRecord object and the helper will derive the correct DOM id automatically.

Supported options:

src — matches the [src] attribute (useful for lazy-loaded frames)
target — matches the [target] attribute
loading — matches the [loading] attribute
count — expected number of matching frames, defaults to 1

You can also pass a block to assert the frame's contents:

assert_turbo_frame "article_1" do
  assert_select "h1", text: "Edit"
  assert_select "form"
end

Nested frames can be asserted the same way:

assert_turbo_frame "article_1" do
  assert_turbo_frame "article_1_comments", loading: "lazy", src: article_comments_path(article)
end

assert_no_turbo_frame

Asserts that the response does not contain a matching <turbo-frame> element. Accepts the same options as assert_turbo_frame.

Practical Examples

Let's look at a common pattern: a lazily-loaded "related articles" section on an article page.

The page initially renders a lazy-loaded frame and Turbo automatically fetches its content when it enters the viewport.

The controller:

# app/controllers/articles_controller.rb

class ArticlesController < ApplicationController
  before_action :set_article, only: %i[show related]

  def show
  end

  def related
    @related_articles = Article.related_to(@article).limit(5)
  end

  private

  def set_article
    @article = Article.find(params[:id])
  end
end

Article.related_to(@article) returns articles in the same category excluding the article itself.

The article show page renders a lazy-loaded frame:

<!--app/views/articles/show.html.erb-->

<%= turbo_frame_tag "related_articles",
      src: related_article_path(@article),
      loading: :lazy,
      target: :_top do %>
  <p>Loading related articles...</p>
<% end %>

target: :_top ensures that links inside the frame (to articles) trigger full-page navigation.

When the frame is requested, the related action returns the content:

<!--app/views/articles/related.html.erb-->

<%= turbo_frame_tag "related_articles" do %>
  <h2>Related articles</h2>
  <ul>
    <% @related_articles.each do |article| %>
      <li><%= link_to article.name, article %></li>
    <% end %>
  </ul>
<% end %>

Testing the Frame Placeholder

The initial page response should contain the frame placeholder with the expected attributes:

# test/controllers/articles_controller_test.rb

test "show renders the lazy related articles frame" do
    article = articles(:ruby_one)

    get article_url(article)

    assert_response :success

    assert_turbo_frame "related_articles", src: related_article_path(article), target: "_top", loading: "lazy" do
      assert_select "p", text: "Loading related articles…"
    end
  end

No Turbo-Frame header is needed here because this is a normal page request. We're testing that the page includes the lazy-loaded frame, not the request that populates it.

Testing the Loaded Frame Content

To test the frame contents, simulate the request Turbo would make when loading the frame:

# test/controllers/articles_controller_test.rb

test "related renders articles from the same category" do
  article = articles(:ruby_one)

  get related_article_url(article), headers: { "Turbo-Frame" => "related_articles" }

  assert_response :success

  assert_turbo_frame "related_articles" do
    assert_select "h2", text: "Related articles"

    assert_select "a", text: articles(:ruby_two).name
    assert_select "a", text: articles(:rails_one).name, count: 0
  end
end

What Integration Tests Won't Catch

Integration tests are excellent for verifying server-side behavior, but they cannot test everything about Turbo Frames.

In particular, they won't verify:

Whether Turbo successfully swaps the frame content in the browser
Focus management after a frame update
Scroll position preservation
JavaScript interactions triggered by frame loads
Timing-related issues and race conditions

For scenarios where browser behavior is part of the functionality, system tests with Capybara are still the right tool.

Summary

Rails integration tests can simulate Turbo Frame requests by sending the Turbo-Frame header, while assert_turbo_frame and assert_no_turbo_frame make it easy to verify the response.

The basic workflow is:

Send a request with the Turbo-Frame header when testing a frame endpoint
Assert the response status
Use assert_turbo_frame or assert_no_turbo_frame
Optionally assert the frame contents with a block

For server-side behavior, this approach is fast, deterministic, and significantly faster and less fragile than system tests.

Do you use integration tests for Turbo Frames, or do you reach for system tests? Let me know in the comments.

Turbo Frames don’t update the URL… unless you do this

Pavel Myslik — Tue, 21 Apr 2026 13:57:37 +0000

Want to try it yourself? A full working demo is here: turbo-advance-vs-replace. Clone it, run bin/setup and follow DEMO.md for more tips.

Turbo Frames are one of the best things about Hotwire. Wrap a part of your page in <turbo-frame>, and navigations inside it become fast partial updates instead of full page reloads. No JavaScript, no API endpoints, just HTML.

But by default frame navigation:

doesn’t touch browser history
doesn’t change the URL
doesn’t create or replace entries

It just fetches HTML and swaps the frame content in place.

Most of the time, that’s perfect. But sometimes you want the URL to reflect state. For sharing, bookmarking, or just making the browser’s Back and Forward buttons behave.

That’s where data-turbo-action comes in.

Let’s look at two real-world cases.

Two options you actually care about

When you promote a frame navigation to a real page visit, you choose:

advance — adds a new entry to browser history (Back goes step by step)
replace — overwrites the current history entry (Back skips it)

Quick rule of thumb:

Use advance when each state is something users may want to revisit: pagination, search results, or filters
Use replace when the state matters for the URL (shareability), but not for history: tabs on a detail page

The choice comes down to one question:

What should the Back button do?

Let's see both in action.

Example 1: pagination with `advance`

Pagination is the obvious advance case.

Each page is a real destination:

you can share ?page=3
refresh keeps your position
back button goes page by page

The view

<%# app/views/articles/index.html.erb %>
<hgroup>
  <h1>Articles</h1>
</hgroup>

<%= turbo_frame_tag "articles", data: { turbo_action: :advance } do %>
  <ul>
    <% @articles.each do |article| %>
      <li>
        <%= link_to article.name, article, data: { turbo_frame: "_top" } %>
      </li>
    <% end %>
  </ul>

  <%== @pagy.series_nav %>
<% end %>

Note: article links use turbo_frame: "_top" to escape the frame and trigger a full Drive navigation instead of a frame swap.

The controller

# app/controllers/articles_controller.rb
class ArticlesController < ApplicationController
  def index
    @pagy, @articles = pagy(Article.all, limit: 10)
  end
end

What happens

Click “Next” a few times and here's how browser history looks:

[/articles] → [?page=2] → [?page=3] → [?page=4]  ← user is here

URL updates on every click
back button goes page by page
refresh keeps the correct page

Important detail: promoting frame navigation to visits means the pushed URLs become real entry points. Your controller must handle them directly — refresh or a cache miss on Back will trigger a full render at that URL.

Pagy handles this nicely, but it’s easy to forget with custom filters.

Example 2: tabs with `replace`

Now imagine tabs on an article detail page: Overview and Metadata.

You want:

URL to reflect the active tab
users to share a specific tab

But you don't want:

back button replaying every tab click

That's a perfect replace.

The view

<article>
  <h1><%= @article.name %></h1>
</article>

<%= turbo_frame_tag "tab_content", data: { turbo_action: :replace } do %>
  <nav class="tabs" style="justify-content: flex-start; gap: 1rem;">
    <% if @active_tab == "overview" %>
      <strong>Overview</strong>
    <% else %>
      <%= link_to "Overview", article_path(@article, tab: "overview") %>
    <% end %>

    <% if @active_tab == "metadata" %>
      <strong>Metadata</strong>
    <% else %>
      <%= link_to "Metadata", article_path(@article, tab: "metadata") %>
    <% end %>
  </nav>

  <%= render "articles/tabs/#{@active_tab}", article: @article %>
<% end %>

<nav>
  <%= link_to "← All Articles", articles_path %>
</nav>

The controller

# app/controllers/articles_controller.rb
class ArticlesController < ApplicationController
  TABS = %w[overview metadata].freeze

  def show
    @article = Article.find(params[:id])
    @active_tab = TABS.include?(params[:tab]) ? params[:tab] : "overview"
  end
end

What happens

Click between tabs a few times and here's how browser history looks:

[/articles] → [/articles/42?tab=metadata]  ← user is here

only one history entry for the article
URL still reflects the active tab
Back returns to /articles

If we'd used advance here, users would have to click Back through every tab. That gets painful fast.

The takeaway

data-turbo-action lets Turbo Frames control browser history.

Without it, frames ignore history completely. With it, you decide how navigation behaves.

Just remember:

What should the Back button do?

Go through states -> advance
Skip intermediate states -> replace

And don’t forget: your controller must handle those URLs on a full page load.

Run into a weird data-turbo-action edge case? Or a case where advance vs replace wasn’t obvious? Drop it in the comments.

Fixing Production Data in Rails: Lessons from a 6,000-Row Backfill

Pavel Myslik — Wed, 25 Mar 2026 13:45:03 +0000

Fixing a bug in production is usually straightforward. But what happens when the data in the database itself is broken? That’s when things get tricky.

I learned this when a routine deploy quietly broke confirmed_at on our Order records. By the time anyone noticed, around 6,000 rows were affected — and dashboards, emails, and downstream services all depended on that field.

The two-line code fix shipped in minutes, but the data backfill required a lot more thought.

The First Naive Attempt

Once we understood the scope of the problem, the first instinct was obvious: fix it fast. Most Rails developers will reach for one of two things here — a quick one-liner in the console, or a small migration that updates the data directly.

Something like this:

Order.where(confirmed_at: nil, status: "confirmed")
     .update_all(confirmed_at: Time.current)

Note: In reality, determining the correct value for confirmed_at was more complicated — we had to derive it from related records and business logic. For the purposes of this article, Time.current keeps the examples simple and focused on the backfill pattern itself.

It looks clean. One line, no fuss. After a two-minute code fix, it feels like the natural next step.

And this is exactly where production backfills could go wrong.

Why This Is Dangerous in Production

At first glance, the one-liner looks harmless — simple, fast, and it works perfectly in development. The problem starts when you run it on real production data.

There are a few risks that are easy to overlook:

No visibility into progress. Once the query starts, you have no idea how many records have been updated or how many are left.
No safe way to restart. If the process stops halfway — timeout, a deploy, a dropped connection — you don't know what state the data is in.
No way to preview the change. There's no dry run. Running it once already changes the data.
Hard to test properly. You can't write a meaningful test for a console one-liner or an inline migration. If the logic is wrong, you find out in production.
Large transactions put pressure on the database. Updating thousands of rows in a single query can lock tables and slow down the app for real users.

The problem isn't the syntax. It's that once it starts, you've handed over control — and when other systems depend on this data being correct, that's a risk you don't want to take.

A Safer Approach

Instead of trying to fix everything in one query, we decided to treat the backfill like real code.

Not a console one-liner.
Not an inline migration.
A small Ruby class that lives in the repository and can be tested like anything else.

Something like this:

lib/backfills/backfill_confirmed_at.rb

The idea is simple:

the script only triggers the backfill
all the logic lives in a dedicated class
the class can be tested safely before anything runs in production

This keeps the backfill predictable, restartable, and — most importantly — verifiable before it touches a single row.

The Backfill Class

# lib/backfills/backfill_confirmed_at.rb

module Backfills
  class BackfillConfirmedAt
    attr_reader :dry_run, :logger

    def initialize(dry_run: false, logger: Rails.logger)
      @dry_run = dry_run
      @logger  = logger
    end

    def run
      log "Starting | mode: #{dry_run ? 'DRY RUN' : 'LIVE'}"

      processed = 0

      orders.find_each do |order|
        if dry_run
          log "[DRY RUN] Would update Order ##{order.id}"
        else
          order.update_columns(confirmed_at: confirmed_at)
          log "Updated Order ##{order.id}"
        end

        processed += 1

      rescue StandardError => e
        log "Error processing Order #{order.id}: #{e.message}"
      end

      log "Done. Processed: #{processed}"
    end

    private

    def log(message) = logger.info "[Backfills::BackfillConfirmedAt] #{message}"

    def orders = Order.where(confirmed_at: nil, status: "confirmed").order(:id)

    # In reality, the more complex logic of calculating the date
    def confirmed_at = Time.current
  end
end

Testing the Backfill Class

One of the biggest advantages of extracting the logic into a class is that you can test it like any other Ruby code — before running anything in production.

Here are a few tests that cover the most important cases:

# spec/lib/backfills/backfill_confirmed_at_spec.rb

RSpec.describe Backfills::BackfillConfirmedAt do
  let(:null_logger) { Logger.new(nil) }

  describe "#run" do
    let!(:order) { create(:order, status: "confirmed", confirmed_at: nil) }

    context "when dry_run is enabled" do
      it "does not update any records" do
        described_class.new(dry_run: true, logger: null_logger).run

        expect(order.reload.confirmed_at).to be_nil
      end
    end

    context "when order is confirmed with missing confirmed_at" do
      it "updates confirmed_at" do
        described_class.new(logger: null_logger).run

        expect(order.reload.confirmed_at).not_to be_nil
      end
    end

    context "when order already has confirmed_at" do
      let(:timestamp) { 2.days.ago }

      before { order.update(confirmed_at: timestamp) }

      it "does not overwrite it" do
        described_class.new(logger: null_logger).run

        expect(order.reload.confirmed_at).to be_within(1.second).of(timestamp)
      end
    end

    context "when order has a different status" do
      before { order.update(status: "pending") }

      it "does not touch it" do
        described_class.new(logger: null_logger).run

        expect(order.reload.confirmed_at).to be_nil
      end
    end
  end
end

Notice that we pass a null_logger to keep the test output clean — no need to see backfill logs while running the test suite.

These tests won't catch every edge case, but they give you enough confidence to run the backfill knowing the core logic has been verified.

Running the Backfill

The script becomes very simple — it only decides whether we run a dry run or the real update:

# script/backfill_confirmed_at.rb

dry_run = ARGV.include?("--dry-run")

Backfills::BackfillConfirmedAt.new(dry_run: dry_run).run

Always Start With a Dry Run

Before touching any production data, always preview what would change first:

rails runner script/backfill_confirmed_at.rb --dry-run

The output will look something like this:

[Backfills::BackfillConfirmedAt] Starting | mode: DRY RUN
[Backfills::BackfillConfirmedAt] [DRY RUN] Would update Order #10042
[Backfills::BackfillConfirmedAt] [DRY RUN] Would update Order #10051
[Backfills::BackfillConfirmedAt] [DRY RUN] Would update Order #10063
...
[Backfills::BackfillConfirmedAt] Done. Processed: 6000

This gives you a chance to verify a few things before anything is written:

Is the scope correct? Spot-check a few IDs directly in the database.
Does the number of affected records match your expectations? If you expected 6,000 rows but the dry run shows 10,000, something is wrong.
Are there any surprising records? Maybe some orders have a status you didn't account for.

Dry run costs you a few minutes.
A botched live backfill can cost you hours.

Then Run It For Real

When everything looks correct:

rails runner script/backfill_confirmed_at.rb

If you want even more control, consider extending the backfill class with a limit: option to test on a small subset first, or a configurable batch_size: for larger datasets.

How to Safely Stop the Running Backfill

One of the hidden benefits of this approach is that you can stop the script at any time — without worrying about leaving the data in a broken state.

Because find_each processes and commits records one by one, each update is independent. If you stop the script after 2,000 records, those 2,000 rows are correctly updated and stay that way. The remaining records are simply untouched.

To stop the script, a simple Ctrl+C is enough. When you're ready to continue, just run it again. The scope automatically skips already-updated records and picks up where it left off.

This is the key difference from update_all or an inline migration. A large single query either completes fully or rolls back entirely. If something goes wrong halfway through, you're back to square one.

With batch processing, interrupting is not a failure. It's just a pause.

The Workflow We Follow Now

Not every data fix needs this treatment. If you're updating a handful of records, a quick one-liner in the console is perfectly fine.

But once you're dealing with thousands of rows — especially when other systems depend on that data — it's worth slowing down and following a simple process.

1. Understand the scope first

Before writing a single line of code, run a COUNT query on production. Know exactly how many records are affected and confirm what the correct value should be.

2. Write the backfill class

Extract all logic into a dedicated class in lib/backfills/. Add a dry_run option and logging from the start.

3. Test it

Write at least a few basic tests before running anything. This is the step that's easiest to skip under pressure, and the one you'll be most grateful for.

4. Dry run on production

Run with --dry-run first and review the output carefully. Verify the record count matches your expectations and spot-check a few IDs directly in the database.

5. Run it for real

Only when the dry run looks correct. Monitor the logs as it runs — that's what they're there for.

Final Thoughts

The irony of this whole situation was that the code fix took two minutes. The data fix took almost a day — not because it was technically hard, but because we wanted to do it right.

That ratio is worth remembering. A careless backfill can easily cause more damage than the original bug. Treating it like real code — with tests, dry runs, and logging — is not over-engineering. It's just respect for the data your users depend on.

Next time you're staring at thousands of broken records, resist the one-liner. Take the extra hour. Your future self will thank you.

What does your backfill process look like? I'm curious whether others reach for a similar pattern — or something completely different. Let me know in the comments.

I Thought My Rails Query Was Fine — Until NULL Ate My Data

Pavel Myslik — Wed, 11 Mar 2026 13:02:16 +0000

I ran into this while working on a task where I needed to process all contracts that were not coming from SAP.

At first, the query looked perfectly fine:

Contract.where.not(source: 'sap')

Then I double-checked the result by counting returned objects — and something didn’t add up.

You write a Rails query.
It looks correct.
It runs without errors.

But it's quietly hiding records from you.

Welcome to one of the most common — and maybe most dangerous — SQL gotchas.

The Setup

Imagine you have a contracts table with a source column — which is nullable.

Some contracts have:

source = 'sap'
source = 'web'
and some have NULL

Now you want to count all contracts that are not from 'sap'.

Sounds simple:

Contract.where.not(source: 'sap').count
# => 68

68 contracts. Looks reasonable.

But to be sure, I double-checked using Ruby:

Contract.reject { |c| c.source == 'sap' }.size
# => 310

Wait... 310?

Where did 242 records go?

The Problem: NULL Is Not a Value

In SQL, NULL does not mean empty.

It means unknown.

That distinction changes everything.

When SQL evaluates:

source != 'sap'

there are three possible outcomes:

'web'     != 'sap'  => TRUE  (included)  
'sap'     != 'sap'  => FALSE (excluded)  
NULL      != 'sap'  => NULL  (excluded)

That third row is the trap.

NULL != 'sap' does not return TRUE.

It returns NULL.

And in SQL’s three-valued logic, the WHERE clause only keeps rows where the condition is TRUE.

FALSE is excluded.
NULL is also excluded.

Silently.

This isn’t just an issue with !=. Any comparison or negation— <, >, NOT LIKE, NOT IN—can silently exclude NULL rows.

The Fix

Here are three common ways to handle this safely, depending on your database and preference:

Option 1: Rails-style `.or` with `where.not`

Contract.where.not(source: 'sap')
        .or(Contract.where(source: nil))
        .count
# => 310

Rails-native syntax.
Includes all NULL values.
Works on any database supported by Rails.

Option 2: Explicitly include NULLs in SQL with `OR`

Contract.where("source != ? OR source IS NULL", 'sap')
        .count
# => 310

Simple SQL pattern.
Works reliably across most databases (PostgreSQL, MySQL, SQLite).

Option 3: Use `IS DISTINCT FROM` (PostgreSQL)

Contract.where("source IS DISTINCT FROM ?", 'sap')
        .count
# => 310

PostgreSQL-specific.
NULL is treated like a regular value.

The Takeaway

NULL didn’t break my query. It behaved exactly as SQL intended.

That’s what makes it dangerous — no error, no warning, no sign anything went wrong. Just missing data, quietly waiting for you to notice.

Once you understand that NULL means unknown, not empty, the behavior starts to make sense.

Until then… it can silently cost you 242 records.

Have you ever shipped a bug caused by NULL hiding in a query?

Stop Using .any? the Wrong Way in Rails

Pavel Myslik — Tue, 24 Feb 2026 15:30:27 +0000

A single block passed to .any? can silently load thousands of records into memory.

No warnings. No errors. Just unnecessary objects.

And most Rails developers don’t notice it.

You’ve probably used both .any? and .exists? in your Rails app without thinking twice. They both answer the same simple question:

Is there at least one record?

But under the hood, they can behave very differently.

In this article, we’ll look at what actually happens when you call each method, when to use which, and how to avoid a common performance trap.

The Basics: Same Query, Same Result

If you just need to check whether a relation contains any records at all, both .any? and .exists? generate the same efficient query.

user.posts.any?
# SELECT 1 AS one FROM "posts" WHERE "posts"."user_id" = 1 LIMIT 1

user.posts.exists?
# SELECT 1 AS one FROM "posts" WHERE "posts"."user_id" = 1 LIMIT 1

No objects are loaded into memory.
No full table scan.

Both methods ask the database a simple yes/no question and return immediately after finding the first match.

The same applies when you chain .where — as long as you don’t pass a block to .any?:

user.posts.where(published: true).any?
# SELECT 1 AS one FROM "posts"
# WHERE "posts"."user_id" = 1 AND "posts"."published" = true
# LIMIT 1

user.posts.where(published: true).exists?
# SELECT 1 AS one FROM "posts"
# WHERE "posts"."user_id" = 1 AND "posts"."published" = true
# LIMIT 1

So if this is all you need, pick whichever reads better in your code.

There’s no performance difference here.

Where Things Get Dangerous: `.any?` With a Block

The moment you pass a block to .any?, Rails completely changes its behavior.

Instead of asking the database, it loads every matching record into memory and filters in Ruby:

user.posts.any? { |post| post.published? }
# SELECT "posts".* FROM "posts" WHERE "posts"."user_id" = 1

That single line:

Loads all posts
Instantiates an ActiveRecord object for each one
Iterates over them in Ruby
Just to return boolean

It might look harmless in development.

But in production?

If a user has 50,000 posts, you just loaded 50,000 objects into memory to check if one of them is published.

Why This Happens

Here’s how .any? is implemented in Rails:

def any?(*args)
  return false if @none

  return super if args.present? || block_given?
  !empty?
end

If a block is given, Rails delegates to Enumerable#any?.

And Enumerable#any? needs the full collection in memory.

You’ve effectively moved filtering from SQL to Ruby.

The Fix: Let the Database Do the Work

Push the condition into SQL:

user.posts.exists?(published: true)
# SELECT 1 AS one FROM "posts"
# WHERE "posts"."user_id" = 1 AND "posts"."published" = TRUE

One row
One column
Stops at the first match
No object instantiation

Same result. Much lower cost.

When `.any?` Is Actually the Right Choice

There is one important exception.

If the relation is already loaded, .any? will not hit the database again.

For example:

users = User.includes(:posts)

users.each do |user|
  user.posts.any? { |post| post.published? } # no extra query
end

Because posts were preloaded, .any? works entirely in memory.

In this case:

.any? → no additional query
.exists? → forces a new SQL query

So using .exists? here could actually introduce unnecessary database calls — potentially even an N+1 pattern.

Rails internally checks whether the relation is loaded.
If it is, .any? behaves like a normal Ruby collection.

A Better Rule of Thumb

Relation not loaded → prefer .exists?
Relation already loaded → .any? is perfectly fine
.any? with a block → avoid on ActiveRecord relations
.present? for existence → avoid on ActiveRecord relations

Final Thought

Before calling .any?, ask yourself:

Am I checking existence — or am I about to load an entire collection?

Small differences in ActiveRecord APIs can have real production impact.

Have you ever spotted this in a real codebase?

This is part of a small series exploring subtle ActiveRecord behaviors that can impact performance.

DEV Community: Pavel Myslik

Testing Turbo Frames in Rails Without a Browser

How a Turbo Frame Request Works

Simulating a Turbo Frame Request in Tests

Turbo Frame Test Helpers

assert_turbo_frame

assert_no_turbo_frame

Practical Examples

Testing the Frame Placeholder

Testing the Loaded Frame Content

What Integration Tests Won't Catch

Summary

Turbo Frames don’t update the URL… unless you do this

Two options you actually care about

Example 1: pagination with advance

The view

The controller

What happens

Example 2: tabs with replace

The view

The controller

What happens

The takeaway

Fixing Production Data in Rails: Lessons from a 6,000-Row Backfill

The First Naive Attempt

Why This Is Dangerous in Production

A Safer Approach

The Backfill Class

Testing the Backfill Class

Running the Backfill

Always Start With a Dry Run

Then Run It For Real

How to Safely Stop the Running Backfill

The Workflow We Follow Now

Final Thoughts

I Thought My Rails Query Was Fine — Until NULL Ate My Data

The Setup

The Problem: NULL Is Not a Value

The Fix

Option 1: Rails-style .or with where.not

Option 2: Explicitly include NULLs in SQL with OR

Option 3: Use IS DISTINCT FROM (PostgreSQL)

The Takeaway

Stop Using .any? the Wrong Way in Rails

The Basics: Same Query, Same Result

Where Things Get Dangerous: .any? With a Block

Why This Happens

The Fix: Let the Database Do the Work

When .any? Is Actually the Right Choice

A Better Rule of Thumb

Final Thought

Example 1: pagination with `advance`

Example 2: tabs with `replace`

Option 1: Rails-style `.or` with `where.not`

Option 2: Explicitly include NULLs in SQL with `OR`

Option 3: Use `IS DISTINCT FROM` (PostgreSQL)

Where Things Get Dangerous: `.any?` With a Block

When `.any?` Is Actually the Right Choice