使用Minitest测试Ruby catch/throw遇catch时断言失败如何解决？

Let's break down exactly why you're hitting this issue, and how to fix it without ditching your production catch logic.

The Root Cause #

Minitest's assert_throws works by executing the code you pass to it, then listening for uncaught throw signals. If your method already includes a catch :my_error block, that block intercepts the throw :my_error before it ever reaches the assertion. The throw never escapes your method, so assert_throws can't detect it—hence the "Expected :my_error to have been thrown" failure.

Think of it like yelling in a closed room: if someone inside the room catches your yell and doesn't let it escape, the person outside (your test assertion) will never hear it.

Example of the Problem #

Let's say your production code looks like this:

class MyService
  def process_data
    catch :my_error do
      # Some business logic
      throw :my_error if invalid_data?
      # More logic that never runs if we throw
    end
    # Cleanup or fallback logic that runs after the catch
  end
end

Your test might look like this:

class MyServiceTest < Minitest::Test
  def test_process_data_throws_my_error
    service = MyService.new
    assert_throws :my_error do
      service.process_data
    end
  end
end

This test will fail because the catch :my_error inside process_data swallows the throw entirely. The assertion never sees it.

Fixes That Preserve Production Code #

You have a few solid options, depending on what you need to test:

1. Test the Outcome of the Catch Instead of the Throw

Instead of verifying that the throw happens, verify that your catch block does what it's supposed to. For example, if the catch returns a fallback value, or triggers a specific side effect:

def test_process_data_handles_my_error
  service = MyService.new
  # If your catch returns a fallback result
  result = service.process_data
  assert_equal :fallback_result, result

  # Or if your catch triggers a logger call (use a mock)
  logger = Minitest::Mock.new
  logger.expect(:warn, nil, ["Caught my_error"])
  service.stub(:logger, logger) do
    service.process_data
  end
  logger.verify
end

2. Extract the Throw Logic to Test It Separately

If you really need to confirm that the throw occurs, split the code that throws into a separate (possibly private) method. Then test that method directly, bypassing the catch:

# Updated production code
class MyService
  def process_data
    catch :my_error do
      validate_and_process
    end
    # Cleanup logic
  end

  private

  def validate_and_process
    throw :my_error if invalid_data?
    # Actual processing logic
  end
end

# Updated test
class MyServiceTest < Minitest::Test
  def test_validate_and_process_throws_my_error
    service = MyService.new
    assert_throws :my_error do
      # Use `send` to call the private method
      service.send(:validate_and_process)
    end
  end

  def test_process_data_handles_error
    # Test the catch's behavior as in option 1
  end
end

This way, you get to verify both that the throw happens when it should, and that your production code correctly catches and handles it.

3. Temporarily Disable the Catch for Testing (Last Resort)

If refactoring isn't an option, you can use a stub to override the catch logic during testing. This is less ideal, but works if you're stuck:

def test_process_data_throws_my_error
  service = MyService.new
  # Stub the catch block to re-throw instead of handling
  service.stub(:catch, ->(sym) { yield }) do
    assert_throws :my_error do
      service.process_data
    end
  end
end

Note: This relies on how your code is structured, so it might not work for all cases. Stick to options 1 or 2 if possible.

Key Takeaway #

assert_throws only detects throws that aren't caught within the code block you pass to it. Since your production code needs the catch, you have to adjust your testing strategy to either validate the catch's impact, or isolate the throw logic for direct testing.

内容的提问来源于stack exchange，提问作者Ben