Impact on Rails Controller Tests

Oct 13, 2025 by talynt.org 68 views

Introduction

Audited is a popular gem used in Ruby on Rails applications to track changes to models. However, recent changes to the Audited.store behavior have introduced issues with controller tests. In this article, we will explore the changes made to Audited.store and their impact on Rails controller tests.

Changes to Audited.store

There have been two significant changes to Audited.store in recent versions of the gem.

Change from 5.3.0 to 5.4.0

The first change occurred between versions 5.3.0 and 5.4.0. In this change, the definition of Audited.store was modified to use RequestStore. This change broke the persistence of SomeModel.auditing_enabled after a controller action.

Change from 5.4.3 to 5.6.0

The second change occurred between versions 5.4.3 and 5.6.0. In this change, the implementation of Audited.store was modified. Audit.store is now cleaned up in the before_action step of the controller, leading to the change being audited even if SomeModel.auditing_enabled is false. Post-action, the store is still emptied.

Impact on Rails Controller Tests

The changes to Audited.store have a significant impact on Rails controller tests. In particular, the change from 5.4.3 to 5.6.0 has introduced issues with tests that rely on the persistence of SomeModel.auditing_enabled.

Example Test Case

The following test case demonstrates the issue:

test 'can skip auditing' do
  book_copy = book_copies(:poe_poetry_one)

  BookCopy.auditing_enabled = false

  # assertion holds in audited 5.3.0, 5.4.0 and 5.5.0
  # assertion does not hold in 5.6.0
  assert_no_difference 'Audited::Audit.count' do
    patch(
      book_copy_path(book_copy.id),
      params: {
        book_copy: {
          state: 'acceptable'
        }
      }
    )
  end

  assert_response :success

  # Assertions holds in audited 5.3.0
  # but not in audited 5.4.0 or 5.5.0 or 5.6.0
  assert_equal false, BookCopy.auditing_enabled
end

In this test case, we set BookCopy.auditing_enabled to false and then perform a patch request to update a book copy. We then assert that the auditing is disabled and that the audit count has not changed.

However, in versions 5.6.0 and later, the change is audited despite setting BookCopy.auditing_enabled to false. This is because Audit.store is cleaned up in the before_action step of the controller, leading to the change being audited even if auditing is disabled.

Conclusion

In conclusion, the changes to Audited.store have introduced issues with Rails controller tests. The change from 5.4.3 to 5.6.0 has broken the persistence of SomeModel.auditing_enabled, leading to changes being audited even if auditing is disabled. This has significant implications for test cases that rely on the persistence of auditing settings.

Recommendations

To mitigate these issues, we recommend the following:

Upgrade to a later version of Audited: If possible, upgrade to a later version of Audited that has fixed these issues.
Use a different auditing gem: Consider using a different auditing gem that does not have these issues.
Modify test cases: Modify test cases to account for the changes in Audited.store behavior.

Introduction

In our previous article, we explored the changes to Audited.store and their impact on Rails controller tests. In this article, we will answer some frequently asked questions (FAQs) related to these changes.

Q: What are the changes to Audited.store?

A: There have been two significant changes to Audited.store in recent versions of the gem. The first change occurred between versions 5.3.0 and 5.4.0, where the definition of Audited.store was modified to use RequestStore. The second change occurred between versions 5.4.3 and 5.6.0, where the implementation of Audited.store was modified to clean up Audit.store in the before_action step of the controller.

Q: How do these changes affect Rails controller tests?

A: The changes to Audited.store have a significant impact on Rails controller tests. In particular, the change from 5.4.3 to 5.6.0 has broken the persistence of SomeModel.auditing_enabled, leading to changes being audited even if auditing is disabled.

Q: What is the impact of these changes on test cases that rely on the persistence of auditing settings?

A: The changes to Audited.store have broken the persistence of auditing settings, leading to changes being audited even if auditing is disabled. This has significant implications for test cases that rely on the persistence of auditing settings.

Q: How can I modify my test cases to account for these changes?

A: To modify your test cases to account for these changes, you can use the following strategies:

Upgrade to a later version of Audited: If possible, upgrade to a later version of Audited that has fixed these issues.
Use a different auditing gem: Consider using a different auditing gem that does not have these issues.
Modify test cases: Modify test cases to account for the changes in Audited.store behavior.

Q: What are some best practices for testing auditing settings in Rails controller tests?

A: Here are some best practices for testing auditing settings in Rails controller tests:

Use a separate test environment: Use a separate test environment to test auditing settings, to avoid conflicts with other tests.
Use a test-specific auditing gem: Use a test-specific auditing gem to avoid conflicts with the main auditing gem.
Test auditing settings in isolation: Test auditing settings in isolation, to avoid conflicts with other tests.
Use a mocking library: Use a mocking library to mock out the auditing gem, to avoid conflicts with the main auditing gem.

Q: How can I troubleshoot issues related to Audited.store changes of behavior?

A: To troubleshoot issues related to Audited.store changes of behavior, you can use the following strategies:

Check the Audited.store documentation: Check the Audited.store documentation to see if there are any known issues or workarounds.
Check the Audited.store changelog: Check the Audited.store changelog to see if there are any changes that may be causing the issue.
Use a debugging tool: Use a debugging tool to debug the Audited.store code and identify the issue.
Reach out to the Audited.store community: Reach out to the Audited.store community for help and support.

By following these best practices and troubleshooting strategies, you can ensure that your Rails controller tests are accurate and reliable, even in the face of changes to Audited.store behavior.