Enable transactional fixtures in dummy app's specs - #943
Conversation
|
The Ruby 2.5, 2.6, and 2.7 specs are failing in CI as they all use Rails 6.1, which depends on the concurrent-ruby gem requiring the logger gem, which is no longer the case. This was fixed upstream in Rails (rails/rails#54264), but only backported as far back at Rails 7.0, not 6.1. If you're intent in keeping support (at least in CI) for Rails 6.1, I can look to conditionally restrict the version of concurrent-ruby used to avoid the issue. Alternatively, you could look to bump the minimum version of Rails supported. Rails itself only supports back to 7.0 for security issues. |
|
I misspoke on CI not surfacing this issue as I think #944's failures are surfacing it. While CI gets a fresh DB for each run, the records created in each test are likely leaking into the following tests. It's certainly amplified outside CI, as locally your DB would be re-used for each run, not just the tests within a single run, like CI. I suppose it hasn't surfaced in CI as the tests must be coincidentally written in a way where having extra records in the database doesn't accidentally affect the assertions. |
This wraps each example in a transaction that's rolled back at the end of the example to avoid records leaking from one test to the next. Without this, if you repeatedly run tests, your database will repeatedly grow, and depending on your assertions, may fail due to data from previous test runs. CI wouldn't have surfaced this issue as it creates a new DB for each run.
436e432 to
25f5dfe
Compare
This wraps each example in a transaction that's rolled back at the end of the example to avoid records leaking from one test to the next.
Without this, if you repeatedly run tests, your database will repeatedly grow, and depending on your assertions, may fail due to data from previous test runs.
CI wouldn't have surfaced this issue as it creates a new DB for each run.