test_data 0.2.0 → 0.2.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: b4b24762c44d8997a2c66d9dde519931efe100390e3f075defdbbc777cb6a1c6
-  data.tar.gz: 5709a9832370b6047d1f3c68b837558a62fd858912b6d9f9afb41e3a7119898f
+  metadata.gz: 84a9fc3fe7b3dda0cf1ebdc775c9191757d21de11e033189c6450b91f63332e7
+  data.tar.gz: 0a47179f0607d9c57f63706e35de176b14d93989c6e5406094524a0fb3b09704
 SHA512:
-  metadata.gz: 448a864a21894a44ffa3408763cbe0c92a7240da6612d2409dcbe494b00069dfc0138a3e9de254bbf965faef9e1e39e92eda203ef47d202b733b44381c32df7b
-  data.tar.gz: cdf0687b88e0a2692eecfcaa25f24ae3b25b0383f99356039cbf00b1e432899933a46f52ad45d0abe16c3f86d006401ba1fba91478f231bbfe19bc551bfd4386
+  metadata.gz: 4c10de3f9e234ae53e47553d099612dc7474cb3e98022b6a953d60beb8da3f502b00f506f29729dad0a9eb37c8e7f05a662263963300d7c531f48fef660c9173
+  data.tar.gz: d718e34070ca15bd9d0e27c75789e170e42da183fac8efc973404d9cea909ce984453f9393277b37ad36ff42fa4866c66de14d2a82a149ae536f0555c2f5f52d

data/.standard.yml

@@ -0,0 +1,2 @@
+ruby_version: 2.4.0
+

data/CHANGELOG.md

@@ -1,3 +1,10 @@
+# unreleased
+
+- Adds several lifecycle hooks:
+  - config.after_test_data_load
+  - config.after_test_data_truncate
+  - config.after_rails_fixture_load
+
 # 0.2.0
 
 - BREAKING CHANGES: Remove or rename a bunch of APIs that aren't quite necessary

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    test_data (0.2.0)
+    test_data (0.2.1)
       railties (~> 6.0)
 
 GEM

data/README.md

@@ -1,9 +1,5 @@
 # The `test_data` gem
 
-**HEADS UP: 0.2.0 made a whole bunch of breaking changes to the public API and
-we haven't finished rewriting the README yet. Please bear with us while we work
-through it. 🙇**
-
 `test_data` does what it says on the tin: it provides a fast & reliable system
 for managing your Rails application's test data.
 
@@ -22,23 +18,24 @@ What it does:
   files, no precarious approximations of realism: **real data created by your
   app**
 
-* Exposes a simple API for ensuring that each of your tests will against
-  pristine data, whether the test depends on test_data, an empty database, or
-  Rails fixtures
+* Exposes a simple API for ensuring that your data will be pristine for each of
+  your tests, whether the test depends on test_data, an empty database, or Rails
+  fixtures
 
 * Safeguards your tests from flaky failures and supercharges your build by
   providing a sophisticated transaction manager that isolates each test while
   ensuring your data is only loaded once
 
 If you've despaired over the seeming inevitability that all Rails test suites
-will eventually grow to become slow, incomprehensible, and brittle, then this
-gem is for you! And even if you're [a factory_bot
+will eventually grow to become slow, flaky, and incomprehensible, then this gem
+is for you! And even if you're [a factory_bot
 fan](https://twitter.com/searls/status/1379491813099253762?s=20), we hope you'll
 be open to the idea that [there might be a better way](
 #but-we-use-and-like-factory_bot-and-so-i-am-inclined-to-dislike-everything-about-this-gem).
 
 _[Full disclosure: because the gem is still brand new, it makes a number of
-[assumptions](#assumptions) and may not work for every project just yet.]_
+[assumptions](#assumptions)—chief among them being that **Postgres & Rails 6+
+are required**—so it may not work for every project just yet.]_
 
 ## Documentation
 
@@ -46,10 +43,9 @@ This gem requires a lot of documentation—not because `test_data` does a lot of
 things, but because managing one's test data is an inherently complex task. If
 one reason Rails apps chronically suffer from slow tests is that other
 approaches oversimplify test data management, it stands to reason that any
-discomfort caused by `test_data`'s scope may not indicate _unnecessary
-complexity_ so much as highlight how much acclimatization is needed to adopt the
-necessary diligence to achieve fast, isolated tests that scale with your
-application.
+discomfort caused by `test_data`'s scope may not be _unnecessary complexity_ but
+instead be an indication of how little of the problem's _essential complexity_
+we have reckoned with to this point.
 
 1. [Getting Started Guide](#getting-started-guide)
     1. [Install and initialize `test_data`](#step-1-install-and-initialize-test_data)
@@ -70,14 +66,26 @@ application.
     * [test_data:create_database](#test_datacreate_database)
     * [test_data:drop_database](#test_datadrop_database)
 4. [API Reference](#api-reference)
-    * [TestData.config](#testdataconfig)
     * [TestData.uses_test_data](#testdatauses_test_data)
     * [TestData.uses_clean_slate](#testdatauses_clean_slate)
-    * [TestData.prevent_rails_fixtures_from_loading_automatically!](#testdataprevent_rails_fixtures_from_loading_automatically)
     * [TestData.uses_rails_fixtures(self)](#testdatauses_rails_fixtures)
+        * [TestData.prevent_rails_fixtures_from_loading_automatically!](#testdataprevent_rails_fixtures_from_loading_automatically)
+    * [TestData.config](#testdataconfig)
     * [TestData.insert_test_data_dump](#testdatainsert_test_data_dump)
 5. [Assumptions](#assumptions)
 6. [Fears, Uncertainties, and Doubts](#fears-uncertainties-and-doubts) (Q & A)
+    * [But we're already happy with
+      factory_bot!](#but-we-use-and-like-factory_bot-and-so-i-am-inclined-to-dislike-everything-about-this-gem)
+    * [How will we handle merge conflicts in the schema
+      dumps?](#how-will-i-handle-merge-conflicts-in-these-sql-files-if-i-have-lots-of-people-working-on-lots-of-feature-branches-all-adding-to-the-test_data-database-dumps)
+    * [Why can't I manage different SQL dumps for different
+      scenarios?](#why-cant-i-save-multiple-database-dumps-to-cover-different-scenarios)
+    * [These SQL dumps are way too large to commit to
+      git!](#are-you-sure-i-should-commit-these-sql-dumps-theyre-way-too-big)
+    * [Tests shouldn't rely on shared test data if they don't need
+      to](#tests-shouldnt-use-shared-test-data-they-should-instantiate-the-objects-they-need)
+    * [My tests aren't as fast as they should
+      be](#im-worried-my-tests-arent-as-fast-as-they-should-be)
 7. [Code of Conduct](#code-of-conduct)
 8. [Changelog](/CHANGELOG.md)
 9. [MIT License](/LICENSE.txt)
@@ -146,20 +154,11 @@ your server (or any command) to create some test data like so:
 ````
 
 The purpose of the `test_data` database is to provide a sandbox in which you
-will manually generate test data by playing aroundo with your app. Once you've
-craeted enough data to drive tests of your application, `test_data` facilitates
-dumping the resulting state of the `test_data` database so that your tests can
-load it into the `test` database. Rather than try to imitate realistic data
-using factories and fixtures (a task which only grows more difficult as your
-models and their associations increase in complexity), your test data will
-always be realistic because your real application will have created it!
-
-The database dumps are meant to be committed in git and versioned alongside your
-tests over the life of the application. Its schema & data are should be
-incrementally migrated over time, just like your production database. (As a
-happy side effect of running your migrations against your test data, this means
-your `test_data` database may help you identify hard-to-catch migration bugs
-early, before being deployed to production!)
+will manually generate test data by playing around with your app. Rather than
+try to imitate realistic data using factories and fixtures (a task which only
+grows more difficult as your models and their associations increase in
+complexity), your test data will always be realistic because your real
+application will have created it!
 
 ### Step 2: Create some test data
 
@@ -186,31 +185,47 @@ number of Rails commands or Rake tasks against its database by setting
 
 _[Aside: If you experience any hiccups in getting your server to work, please
 [open an issue](https://github.com/testdouble/test_data/issues/new) and let us
-know—it may present an opportunity to improve the `test_data:configure` task!]_
+know—it may present an opportunity for us to improve the `test_data:configure`
+task!]_
 
 #### Create test data by using your app
 
 Once the app is running, it's time to generate some test data. You'll know how
 to accomplish this step better than anyone—it's your app, after all!
 
-Our advice? Spend a little time thoughtfully navigating each feature of your app
-in order to generate enough data to be _representative_ of what would be needed
-to test your system's main behaviors (e.g. one `User` for each role, one of each
-kind of `Order`, etc.), while still being _minimal_ enough that the universe of
-data will be comprehensible & memorable to yourself and your teammates. It can
-also help to give new records memorable names, perhaps in keeping with a common
-theme (easier to refer to "Rafael" than "TestUser #1").
-
-If you make a mistake, it's perfectly okay to reset the database and start over!
-Your future tests will be coupled to this data as your application grows and
-evolves, so it's worth taking the time to ensure the foundation is solid. (But
-that's not to say everything needs to be perfect; you can always change things
-or add more data later—you'll just have to update your tests accordingly.)
+A few bits of advice click & type some test data into existence:
+
+* Spend a little time thoughtfully navigating each feature of your app in order
+  to generate enough data to be representative of what would be needed to test
+  them (e.g. one `User` per role, one of each kind of `Order`, etc.)
+* Less is more: the less test data you create, the more meaningful & memorable
+  it will be to yourself and your teammates when writing tests. Don't keep
+  adding test data unless it will allow you to exercise additional application
+  code (e.g. enough `Project` models to require pagination, but not hundreds of
+  them for the sake of looking "production-like")
+* Memorable names can become memes for the team to quickly recall and reference
+  later (if the admin user is named "Angela" and the manager is "Maria", that'll
+  probably serve you better than generic names like "TestUser #1")
+
+If you make a mistake when creating your initial set of test data, it's
+perfectly okay to reset the database and start over! Your future tests will be
+coupled to this data as your application grows and evolves, so it's worth taking
+the time to ensure the foundation is solid. (But that's not to say everything
+needs to be perfect; you can always change things or add more data later—you'll
+just have to update your tests accordingly.)
 
 ### Step 3: Dump your `test_data` database
 
+Once you've created a good sampling of test data by interacting with your app,
+the next step is to flush it from the `test_data` database to SQL files. These
+database dumps are meant to be committed to source control and versioned
+alongside your tests over the life of the application. Additionally, they are
+designed to be incrementally
+[migrated](#step-5-keeping-your-test-data-up-to-date) over time, just like you
+migrate production database with every release.
+
 Once you have your test data how you want it, dump the schema and data to SQL
-files:
+files with the `test_data:dump` Rake task:
 
 ```
 $ bin/rake test_data:dump
@@ -218,12 +233,15 @@ $ bin/rake test_data:dump
 
 This will dump three files into `test/support/test_data`:
 
-* Schema DDL in `schema.sql`
+* `schema.sql` - Schema DDL used to (re-)initialize the `test_data` environment
+  database for anyone looking to update your test data
 
-* Test data in `data.sql`
+* `data.sql` - The test data itself, exported as a bunch of SQL `INSERT`
+  statements, which will be executed by your tests to load your test data
 
-* Non-test data (`ar_internal_metadata` and `schema_migrations` by default) in
-  `non_test_data.sql`
+* `non_test_data.sql` - Data needed to run the `test_data` environment, but
+  which shouldn't be inserted by your tests (the `ar_internal_metadata` and
+  `schema_migrations` tables, by default; see `config.non_test_data_tables`)
 
 You probably won't need to, but these paths can be overridden with
 [TestData.config](#testdataconfig) method. Additional details can also be found
@@ -241,25 +259,34 @@ environment exists only for creating your test data. Your tests will, in turn,
 load the SQL dump of your data into the `test` database, and things will proceed
 just as if you'd been loading [Rails' built-in
 fixtures](https://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures)
-from a set of YAML files—the major difference being that `test_data` databases
-are generated through realistic use, whereas fixtures are defined manually in
-(sometimes painstaking) YAML.
+from a set of YAML files.
 
 ### Step 4: Load your data in your tests
 
 Now that you've dumped the contents of your `test_data` database, you can start
 writing tests that rely on this test data.
 
-To accomplish this, you'll likely want to add hooks to run before & after each
-test—first to load your test data and then to rollback any changes made by the
-test in order to clear the air for the next test. The `test_data` gem
-accomplishes this with its [TestData.uses_test_data](#testdatauses_test_data)
-method.
+To accomplish this, you'll likely want to add hooks to run before each test to
+put the database into whatever state the test needs.
+
+For the simplest case—ensuring your test data is loaded into the `test` database
+and available to your test, you'll want to call the
+[TestData.uses_test_data](#testdatauses_test_data) method at the beginning of
+the test. The first time `uses_test_data` is called, `test_data` will start a
+transaction and insert your test data. On subsequent calls to `uses_test_data`
+by later tests, the transaction will be rolled back to a save point taken just
+after the data was initially loaded, so that each test gets a clean starting
+point without repeatedly executing the expensive SQL operation.
+
+#### If you want every single test to have access to your test data
 
-If you're using (Rails' default)
-[Minitest](https://github.com/seattlerb/minitest) and want to include your test
-data with every test, you could load them in a `setup` hook in
-`ActiveSupport::TestCase`:
+If, for the sake of consistency & simplicity you want every single Rails-aware
+test to have access to your test data, you
+can accomplish this with a single global before-each hook.
+
+If you're using Rails' default
+[Minitest](https://github.com/seattlerb/minitest), you can load it in a `setup`
+hook in `ActiveSupport::TestCase`:
 
 ```ruby
 class ActiveSupport::TestCase
@@ -269,8 +296,8 @@ class ActiveSupport::TestCase
 end
 ```
 
-If you use [RSpec](https://rspec.info), you can accomplish the same thing with
-global `before(:each)` hook in your `rails_helper.rb` file:
+Likewise, if you use [RSpec](https://rspec.info), you can accomplish the same
+thing with global `before(:each)` hook in your `rails_helper.rb` file:
 
 ```ruby
 RSpec.configure do |config|
@@ -280,82 +307,139 @@ RSpec.configure do |config|
 end
 ```
 
-That should be all you need to have access to your test data in each of your
-tests! Your tests will also benefit from the speed and data integrity that comes
-with covering each test's behavior in an always-rolled-back transaction. For
-more information on how all this works, see the [API reference](#api-reference).
-If your test suite is already using fixtures or factories and the above hooks
-just broke everything, check out our [interoperability
-guide](#factory--fixture-interoperability-guide) for help.
+#### If some tests rely on test data and others need a clean slate
+
+Of course, for simple units of code, it may be more prudent to manually create
+the test data they need inline as opposed to relying on a shared source of test
+data. For these tests, you can call
+[TestData.uses_clean_slate](#testdatauses_clean_slate) in a `setup` hook.
 
-If you _don't_ want all of your Rails-aware tests to see this test data (suppose
-you have existing tests that use factories instead), you probably want to use
-[TestData.uses_clean_slate](#testdatauses_clean_slate) to clear data generated
-by this gem out before they run. One way to do that would be to define two test
-types:
+For the best performance, you might consider a mode-switching method that's
+invoked at the top of each test listing like this:
 
 ```ruby
-# Tests using data created by `test_data`
-class TestDataTestCase < ActiveSupport::TestCase
-  setup do
-    TestData.uses_test_data
+class ActiveSupport::TestCase
+  def self.uses(mode)
+    case mode
+    when :clean_slate
+      setup { TestData.uses_clean_slate }
+    when :test_data
+      setup { TestData.uses_test_data }
+    else
+      raise "Invalid test data mode: #{mode}"
+    end
   end
 end
 
-# Tests that don't rely on test_data or Rails fixtures:
-class CleanSlateTestCase < ActiveSupport::TestCase
-  setup do
-    TestData.uses_clean_slate
+# A simple model that will `create` its own data
+class WidgetTest < ActiveSupport::TestCase
+  uses :clean_slate
+  # …
+end
+
+# An integrated test that depends on a lot of data
+class KitchenSinkTest < ActionDispatch::IntegrationTest
+  uses :test_data
+  # …
+end
+```
+
+Or, with RSpec:
+
+```ruby
+module TestDataModes
+  def uses(mode)
+    case mode
+    when :clean_slate
+      before(:each) { TestData.uses_clean_slate }
+    when :test_data
+      before(:each) { TestData.uses_test_data }
+    else
+      raise "Invalid test data mode: #{mode}"
+    end
   end
 end
+
+RSpec.configure do |config|
+  config.extend(TestDataModes)
+end
+
+RSpec.describe Widget, type: :model do
+  uses :clean_slate
+  # …
+end
+
+RSpec.describe "Kitchen sink", type: :request do
+  uses :test_data
+  # …
+end
 ```
 
+#### If your situation is more complicated
+
+If you're adding `test_data` to an existing application, it's likely that you
+won't be able to easily adopt a one-size-fits-all approach to test setup across
+your entire suite. Some points of reference, if that's the situation you're in:
+
+* If your test suite is already using fixtures or factories and the above hooks
+  just broke everything, check out our [interoperability
+  guide](#factory--fixture-interoperability-guide) for help.
+* If you don't want `test_data` managing transactions and cleanup for you and
+  just want to load the SQL dump, you can call
+  [TestData.insert_test_data_dump](#testdatainsert_test_data_dump)
+* For more information on how all this works, see the [API
+  reference](#api-reference).
+
 ### Step 5: Keeping your test data up-to-date
 
 Your app relies on its tests and your tests rely on their test data. This
 creates a bit of a paradox: creating & maintaining test data is _literally_ a
 tertiary concern but simultaneously an inescapable responsibility that will live
 with you for the life of your application. That's true whether you use this gem,
-`factory_bot`, Rails fixtures, or persist your test data manually inside each
-and every test.
+`factory_bot`, Rails fixtures, or something else as a source of shared test
+data.
 
-But `test_data` stores your data as SQL, as opposed to Ruby or YAML. So
-providing a straightforward way to maintain it as your application grows and
-your schema evolves is a going concern of this gem.
-
-Fortunately, because your `test_data` database needs to be maintained for the
-entire life of your application and because production databases need the same
-thing, we already have a fantastic tool for the job: [Rails
+Fortunately, we already have a fantastic tool available for keeping our
+`test_data` database up-to-date over the life of our application: [Rails
 migrations](https://guides.rubyonrails.org/active_record_migrations.html). If
-your migrations are resilient enough for your production data, they should also
-be able to keep your `test_data` database up-to-date.
+your migrations are resilient enough for your production database, they should
+also be able to keep your `test_data` database up-to-date. (As a happy side
+effect of running your migrations against your test data, this means your
+`test_data` database may help you identify hard-to-catch migration bugs early,
+before being deployed to production!)
+
+Whenever you create a new migration or add a major feature, you'll probably need
+to update your test data. Here's how to do it:
 
-Whenever you update your schema, migrate your data, or add a feature that
-necessitates the creation of more test data, you'll need to update your test
-data. Here's a rough outline to updating your `test_data` database:
+* If the current SQL dumps in `test/support/test_data` are newer than your local
+  `test_data` database:
 
-1. If your local `test_data` database is out-of-date with your latest SQL dump
-   files (i.e. if someone has updated the SQL dump and your local Postgres
-   database is out of date), drop it with `rake test_data:drop_database`
+    1. Be sure there's nothing in your local `test_data` database that you added
+       intentionally and forgot to dump, because it's about to be erased
 
-2. Load your schema & data into the `test_data` database with `rake
-   test_data:load`
+    2. Run `rake test_data:drop_database`
 
-3. Run any pending migrations with `RAILS_ENV=test_data bin/rake db:migrate`
+    3. Run `rake test_data:load` to recreate the `test_data` database and load
+       the latest SQL dumps into it
 
-4. If you need to create any additional data, start up the server
-   (`RAILS_ENV=test_data bin/rails s`), just like in [Step
-   2](#step-2-create-some-test-data)
+    4. Run any pending migrations with `RAILS_ENV=test_data bin/rake db:migrate`
 
-5. Export your newly-updated `test_data` database with `rake test_data:dump`
+    5. If you need to create any additional data, start up the server
+       (`RAILS_ENV=test_data bin/rails s`), just like in [Step
+       2](#step-2-create-some-test-data)
 
-6. Ensure your tests are passing and then commit the resulting SQL files
+    6. Export your newly-updated `test_data` database with `rake test_data:dump`
+
+    7. Ensure your tests are passing and then commit the resulting SQL files
+
+* If the local `test_data` database is already up-to-date with the current SQL
+  dumps, follow steps **4 through 7** above
 
 It's important to keep in mind that your test data SQL dumps are a shared,
 generated resource among your team (just like a `structure.sql` or `schema.rb`
 file). As a result, if your team doesn't integrate code frequently or if the
-test data experiences a lot of churn in coincident feature branches, you'd be
-right to be concerned that [the resulting merge conflicts could become
+test data changes frequently, you'd be right to be concerned that [the resulting
+merge conflicts could become
 significant](#how-will-i-handle-merge-conflicts-in-these-sql-files-if-i-have-lots-of-people-working-on-lots-of-feature-branches-all-adding-to-the-test_data-database-dumps),
 so sweeping changes should be made deliberately and in collaboration with other
 contributors.
@@ -364,7 +448,10 @@ _[Aside: some Rails teams are averse to using migrations to migrate data as well
 as schemas, instead preferring one-off scripts and tasks. You'll have an easier
 time of things if you use migrations for both schema and data changes. Here are
 some notes on [how to write data migrations
-safely](https://blog.testdouble.com/posts/2014-11-04-healthy-migration-habits/#habit-4-dont-reference-models).]_
+safely](https://blog.testdouble.com/posts/2014-11-04-healthy-migration-habits/#habit-4-dont-reference-models).
+Otherwise, you'll need to remember to run any ad hoc deployment scripts against
+your `test_data` Rails environment along with each of your other deployed
+environments.]_
 
 ## Factory & Fixture Interoperability Guide
 
@@ -383,8 +470,8 @@ all three, or none-of-the-above.
 
 This section will hopefully make it a little easier to incorporate new
 `test_data` tests into a codebase that's already using `factory_bot` and/or
-Rails fixtures, whether you choose to incrementally rewrite the older tests to
-conform to your `test_data` or not.
+Rails fixtures, whether you choose to incrementally migrate to using `test_data`
+over time.
 
 ### Using `test_data` with `factory_bot`
 
@@ -395,185 +482,43 @@ This section will document some thoughts and strategies for introducing
 
 Depending on the assumptions your tests make about the state of the database
 before you've loaded any factories, it's possible that everything will "just
-work" after adding `TestData.uses_test_data` in a before-each hook (as shown in
-the [setup guide](#step-4-load-your-data-in-your-tests)). So by all means, try
-running your suite after following the initial setup guide and see if the suite
-just passes.
+work" after adding [TestData.uses_test_data](#testdatauses_test_data) in a
+before-each hook (as shown in the [setup
+guide](#step-4-load-your-data-in-your-tests)). So by all means, try running your
+suite after following the initial setup guide and see if the suite just passes.
 
 If you find that your test suite is failing after adding
-`TestData.uses_test_data` to your setup, don't panic! It probably means that you
-have test data and factory invocations that are, when combined, violating unique
-validations or database constraints. Depending on your situation (e.g. the size
-of your test suite, how well you understand the intentions of older tests) you
-might try to resolve these errors one-by-one—usually by updating the offending
-factories or editing your `test_data` database to ensure they steer clear of one
-another. Care should be taken to preserve the conceptual encapsulation of each
-test, however, as naively squashing errors can introduce coupling between your
-factories and your `test_data` database that inadvertently tangles the two
-together (where both test data sources become necessary to interact with the
-system).
-
-If your tests are failing after introducing `test_data` and it's not desirable
-or feasible to work through the individual failures, you can accomplish a clean
-segregation between your factory-dependent tests and your tests that rely on
-`test_data` by wrapping each test that depends on `factory_bot` with
-[TestData.truncate](#testdatatruncate) in a before-each hook and
-[TestData.rollback(:after_data_truncate)](#rolling-back-to-after-test-data-was-truncated)
-in an after-each hook, like this:
+`TestData.uses_test_data` to your setup, don't panic! Test failures are most
+likely caused by the combination of your `test_data` database with the data
+persisted by your factories.
+
+One approach would be to attempt to resolve each such failure one-by-one—usually
+by updating the offending factories or editing your `test_data` database to
+ensure they steer clear of one another. Care should be taken to preserve the
+conceptual encapsulation of each test, however, as naively squashing errors can
+introduce inadvertent coupling between your factories and your `test_data`
+database such that neither can be used independently of the other.
+
+Another approach that the `test_data` gem provides is an additional mode with
+`TestData.uses_clean_slate`, which—when called at the top of a factory-dependent
+test—will ensure that the tables that `test_data` had written to will be
+truncated, allowing the test to create whatever factories it needs without fear
+of conflicts.
 
 ```ruby
 class AnExistingFactoryUsingTest < ActiveSupport::Testcase
-  def setup
-    TestData.truncate
+  setup do
+    TestData.uses_clean_slate
     # pre-existing setup
   end
-
-  def test_stuff
-    #… etc
-  end
-
-  def teardown
-    TestData.rollback(:after_truncate)
-  end
-end
-```
-
-What this will do is complicated and counter-intuitive, but also fast and
-reliable: [TestData.truncate](#testdatatruncate) will first ensure that your
-`test_data` database is loaded inside a transaction, then will truncate that
-data (set the `truncate_these_test_data_tables` [config option](#testdataconfig)
-if necessary), and will finally create _yet another_ transaction save point
-named `:after_data_truncate`. From that point onward, your test is free to
-create all the factories it needs without fear of colliding with whatever you've
-got stored in your `test_data` tables.
-
-_[Why does this approach potentially load all the `test_data` data only to
-immediately truncate it? Because it's actually much faster to truncate a large
-data load in a live transaction, rollback the truncation, and then re-truncate
-the data for a subsequent test than it would be to rollback the large data load
-itself and re-load it for a subsequent test. It's silly but it works.]_
-
-Hopefully one of these approaches, or some combination of them will get your
-test suite passing after you've introduced `test_data`.
-
-#### Separating your `test_data` and factory tests
-
-Just because your tests _can_ access both your `factory_bot` factories and
-`test_data` database doesn't mean they _should_.
-
-Integration tests inevitably become coupled to the data that's available to
-them, and if a test has access to both records created by a factory and a
-`test_data` SQL dump, it is likely to unintentionally become inextricable from
-both. This could result in the test having more ways to fail than necessary and
-make it harder to simplify your test data strategy later. Instead, consider
-explicitly opting into a single type of test data by separating your tests based
-on which source of test data they use.
-
-Every situation will be different, but one strategy that suits a lot of
-circumstances would be to write a class method that runs at test-load time to
-declare and configure the test data strategy for the current test.
-
-Taking from [this
-example](/example/test/integration/better_mode_switching_demo_test.rb) test, you
-could implement a class method like this:
-
-```ruby
-class ActiveSupport::TestCase
-  def self.test_data_mode(mode)
-    case mode
-    when :factory_bot
-      require "factory_bot_rails"
-      include FactoryBot::Syntax::Methods
-
-      setup do
-        TestData.truncate
-      end
-
-      teardown do
-        TestData.rollback(:after_data_truncate)
-      end
-    when :test_data
-      setup do
-        TestData.load
-      end
-
-      teardown do
-        TestData.rollback
-      end
-    end
-  end
-end
-```
-
-And then (without any class inheritance complications), simply declare which
-kind of test you're specifying:
-
-```ruby
-class SomeFactoryUsingTest < ActiveSupport::TestCase
-  test_data_mode :factory_bot
-
-  # … tests go here
-end
-
-class SomeTestDataUsingTest < ActionDispatch::IntegrationTest
-  test_data_mode :test_data
-
-  # etc.
+  # …
 end
 ```
 
-By following an approach like this one, your `test_data` tests won't even see
-your `create_*` factory methods and your `factory_bot` tests won't have access
-to any of your `test_data`, either. From there, you can  migrate tests onto
-`test_data` incrementally, secure in the knowledge that you're not inadvertently
-tangling your tests' dependency graph further.
-
-#### Speeding up your test suite when using factories
-
-##### Addressing redundant data cleanup
-
-After adding `test_data` to your test suite, consider is how database cleanup
-was being handled previously to make sure it isn't unnecessarily truncating
-everything or resetting the transaction between tests. It's possible that your
-suite is relying on Rails' built-in `use_transactional_tests` feature to wrap
-your tests in always-rolled-back transactions, even if you're not using
-fixtures. Or perhaps your suite uses
-[database_cleaner](https://github.com/DatabaseCleaner/database_cleaner) to
-truncate the database before or after each test. In either case, it's important
-to know that by default [TestData.load](#testdataload) and
-[TestData.rollback](#testdatarollback) will start and rollback a nested
-transaction, respectively. That means—so long as they're called at the top of a
-before-each hook and the end of an after-each hook—you might be able to disable
-`use_transactional_tests` or remove your dependency on `database_cleaner` or any
-other custom truncation logic you might have. Even if you get your suite running
-immediately after adding `test_data`, it's still worth taking the time to
-understand what's going on during test setup & teardown, because there may be an
-opportunity to make your tests faster and more comprehensible by eliminating
-redundant clean-up steps.
-
-##### Avoiding truncate rollback churn
-
-It's important to know that if your test suite has a mix of tests that call
-[TestData.load](#testdataload) and tests that call
-[TestData.truncate](#testdatatruncate), each time the test runner switches
-between the two types, each call to `TestData.load` will cause the transaction
-state to be rolled back from
-[:after_data_truncate](#rolling-back-to-after-test-data-was-truncated) to
-[:after_data_load](#rolling-back-to-after-the-data-was-loaded), only for the
-next test to call `TestData.truncate` truncates all the tables again. In
-practice, this shouldn't be too costly an operation, but if your test order is
-randomized you might find that your build will run faster if you separate each
-set of tests at runtime.
-
-Separating your `test_data` and `factory_bot` tests is pretty trivial if you're
-using RSpec, as the
-[tag](https://relishapp.com/rspec/rspec-core/v/3-10/docs/command-line/tag-option)
-feature was built with this sort of need in mind. Otherwise, you might consider
-organizing the tests in different directories and running multiple commands to
-execute them (e.g. `bin/rails test test/test_data_tests` and `bin/rails
-test/factory_tests`). Every CI configuration is different, however, and you may
-find yourself needing to get creative in configuring things to achieve the
-fastest build time.
+If you have a lot of tests, you can find a more sophisticated approaches for
+logically switching between types of test data declaratively above in the
+[getting started
+section](#if-some-tests-rely-on-test-data-and-others-need-a-clean-slate)
 
 ### Using `test_data` with Rails fixtures
 
@@ -584,146 +529,53 @@ permanently committed to the test database actually makes them a little trickier
 to work with. This section will cover a couple approaches for integrating
 `test_data` into suites that use fixtures.
 
-#### Getting your fixtures-dependent tests passing with `test_data`
-
 It's more likely than not that all your tests will explode in dramatic fashion
-as soon as you add `TestData.load` to a `setup` or `before(:each)` hook. Because
-fixtures will be loaded all-at-once then your `test_data` dump will be inserted
-directly on top of them. If everything works, or if you only encounter a few
-errors throughout your test suite (perhaps based on assertions of the `count` of
-a particular model), congratulations! You should still consider mitigating the
-risks of coupling your tests to both data sources ([as discussed
-above](#separating-your-test_data-and-factory-tests)) by migrating completely
-onto `test_data` over time, but no further action is necessary or recommended.
-
-If, however, you find yourself running into non-trivial challenges (like rampant
-validation or constraint errors), `test_data` provides an API that **overrides
-Rails' built-in fixtures behavior with a monkey patch**. If that bold text
-warning wasn't enough to scare you from reading on, here's how to do it.
-
-_[Note that the following requires `use_transactional_data_loader` to be enabled
-in your [config](#testdataconfig), because it depends on transaction
-rollbacks.]_
-
-Here's what you can do if you can't get your fixtures to play nicely with your
-`test_data` dump:
-
-1. Near the top of your test helper, call:
+as soon as you add `TestData.uses_test_data` to a `setup` or `before(:each)`
+hook. Typically, your fixtures will be loaded and committed immediately with
+your `test_data` dump inserted afterward, which makes it exceedingly likely that
+your tests will fail with primary key and unique constraint conflicts. If that's
+the case you find yourself in, `test_data` provides an API that **overrides
+Rails' built-in fixtures behavior with a monkey patch**.
+
+And if that bold text wasn't enough to scare you off, here's how to do
+it:
+
+1. Before your tests have loaded (e.g. near the top of your test helper), call:
    [TestData.prevent_rails_fixtures_from_loading_automatically!](#testdataprevent_rails_fixtures_from_loading_automatically)
-   This will effectively turn
+   This will patch Rails'
    [setup_fixtures](https://github.com/rails/rails/blob/main/activerecord/lib/active_record/test_fixtures.rb#L105)
-   into a no-op, which means that your test fixtures will not be automatically
-   loaded into your test database
+   and effectively render it into a no-op, which means that your test fixtures
+   will not be automatically loaded into your test database
 
-2. In tests that rely on your `test_data` dump, call [TestData.load and
-   TestData.rollback](#step-4-load-your-data-in-your-tests) as you normally
-   would. Because your fixtures won't be loaded automatically, they won't be
-   available to these tests
+2. In tests that rely on your `test_data` dump, call
+   [TestData.uses_test_data](#step-4-load-your-data-in-your-tests) as you
+   normally would. Because your fixtures won't be loaded automatically, they
+   won't be available to these tests
 
 3. In tests that need fixtures, call
-   [TestData.load_rails_fixtures(self)](#testdataload_rails_fixtures)
-   in a before-each hook and
-   [TestData.rollback(:after_load_rails_fixtures)](#rolling-back-to-after-rails-fixtures-were-loaded)
-   in an after-each hook. This will (in an almost comic level of
-   transaction-nesting) ensure your `test_data` dump is loaded in an initial
-   transaction, then ensure that it is truncated in a second transaction, before
-   loading your rails fixtures in a third transaction. These tests will have
-   access to all your fixture data without being tainted by any of your
-   `test_data` data
+   [TestData.uses_rails_fixtures(self)](#testdatauses_rails_fixtures) in a
+   before-each hook. This will first ensure that any tables written to by
+   `test_data` are truncated (as with `TestData.uses_clean_slate`) before
+   loading your Rails fixtures
 
 For example, you might add the following to an existing fixtures-dependent
 test to get it passing:
 
 ```ruby
 class AnExistingFixtureUsingTest < ActiveSupport::Testcase
-  def setup
-    TestData.load_rails_fixtures(self)
+  setup do
+    TestData.uses_rails_fixtures(self)
     # pre-existing setup
   end
 
-  def test_stuff
-    #… etc
-  end
-
-  def teardown
-    TestData.rollback(:after_load_rails_fixtures)
-  end
+  # …
 end
 ```
 
-_[You don't need to worry about whether `TestData.load` has been called
-previously, the loader will infer your intent and ensure that the transaction
-state is correct before loading your fixtures.]_
-
-#### Separating your `test_data` and fixture tests
-
-*This only applies if you had to use
-[TestData.load_rails_fixtures(self)](#testdataload_rails_fixtures) as shown
-above.*
-
-Just [like with factories](#separating-your-test_data-and-factory-tests), you
-might benefit from a test helper to clearly declare whether a test uses fixtures
-or `test_data` right at the top. Following the same pattern, you might do this:
-
-```ruby
-class ActiveSupport::TestCase
-  def self.test_data_mode(mode)
-    case mode
-    when :fixtures
-      fixtures :all
-
-      setup do
-        TestData.load_rails_fixtures(self)
-      end
-
-      teardown do
-        TestData.rollback(:after_load_rails_fixtures)
-      end
-    when :test_data
-      setup do
-        TestData.load
-      end
-
-      teardown do
-        TestData.rollback
-      end
-    end
-  end
-end
-```
-
-Which would allow you to simplify the above fixtures-using test to:
-
-```ruby
-class AnExistingFixtureUsingTest < ActiveSupport::Testcase
-  test_data_mode :fixtures
-
-  def test_stuff
-    #… etc
-  end
-end
-```
-
-#### Improving test suite speed with fixtures
-
-Again, as is [the case with
-factories](#improving-test-suite-speed-with-factories), every time your test
-runner randomly picks a `test_data` test after running a fixtures-dependent
-test, it will roll back your fixtures and the truncation of your `test_data`,
-only to re-truncate your `test_data` data and reload your fixtures for the next
-test that happens to use fixtures. But unlike truncation alone, loading your
-fixtures is a non-trivial operation that can chew up a some serious time as your
-suite runs.
-
-As a result, we strongly encourage breaking up your test suite to avoid this
-churn, even if it means splitting your test run over multiple CLI commands. If
-you're using the Rails test runner and Minitest, that likely means sequestering
-one set of tests to one directory and the other to a different directory, as
-there is no granular control over to how the runner randomizes suites. And for
-RSpec,
-[tagging](https://relishapp.com/rspec/rspec-core/v/3-10/docs/command-line/tag-option)
-each spec and running separate commands for each tag could yield significant
-performance improvements.
+If you've adopted a mode-switching helper method [like the one described
+above](#if-some-tests-rely-on-test-data-and-others-need-a-clean-slate), you
+could of course add a third mode to cover any tests that depend on Rails
+fixtures.
 
 ## Rake Task Reference
 
@@ -768,11 +620,9 @@ This task runs several generators:
   have numerous secrets in this file's `development:` stanza, you may want to
   alias and inherit it into `test_data:` like the `webpacker.yml` generator does
 
-* `config/cable.yml` - In the absences of a configuration stanza,
-  [ActionCable](https://guides.rubyonrails.org/action_cable_overview.html) will
-  assume you're using Redis for tracking Websocket connections, so this
-  generator explicitly specifies `async` instead, since that's the default for
-  `development:`
+* `config/cable.yml` - Simply defines a `test_data:` entry that tells
+  [ActionCable](https://guides.rubyonrails.org/action_cable_overview.html) to
+  use the `async` adapter, since that's also the default for `development`
 
 ### test_data:verify_config
 
@@ -789,8 +639,8 @@ your seed file. Specifically:
 1. Creates the `test_data` environment's database, if it doesn't already exist
 
 2. Ensures the database is non-empty to preserve data integrity (run
-   [test_data:drop_database](#test_datadrop_database) first if it contains
-   outdated test data)
+   [test_data:drop_database](#test_datadrop_database) first if you intend to
+   reinitialize it)
 
 3. Checks to see if a dump of the database already exists (by default, stored in
    `test/support/test_data/`)
@@ -804,8 +654,9 @@ your seed file. Specifically:
 ### test_data:dump
 
 This task is designed to be run after you've created or updated your test data
-and you're ready to run your tests against it. The task creates several plain
-SQL dumps from your `test_data` environment's database:
+in the `test_data` database and you're ready to run your tests against it. The
+task creates several plain SQL dumps from your `test_data` environment's
+database:
 
 * A schema-only dump, by default in `test/support/test_data/schema.sql`
 
@@ -813,13 +664,13 @@ SQL dumps from your `test_data` environment's database:
   `test/support/test_data/data.sql`
 
 * A data-only dump of records that you *don't* want loaded in your tests in
-  `test/support/test_data/non_test_data.sql` (by default, this includes Rails'
+  `test/support/test_data/non_test_data.sql`. By default, this includes Rails'
   internal tables: `ar_internal_metadata` and `schema_migrations`, configurable
-  with [TestData.config](#testdataconfig)'s `non_test_data_tables`)
+  with [TestData.config](#testdataconfig)'s `non_test_data_tables`
 
 Each of these files are designed to be committed and versioned with the rest of
 your application. [TestData.config](#testdataconfig) includes several
-options to control which tables are exported into which group.
+options to control this task.
 
 ### test_data:load
 
@@ -836,7 +687,7 @@ This task will load your SQL dumps into your `test_data` database by:
 4. Warning if there are pending migrations that haven't been run yet
 
 If there are pending migrations, you'll probably want to run them and then
-dump & commit your test data so that they're all up-to-date:
+dump & commit your test data so that they're up-to-date:
 
 ```
 $ RAILS_ENV=test_data bin/rake db:migrate
@@ -849,278 +700,285 @@ This task will create the `test_data` environment's database if it does not
 already exist. It also
 [enhances](https://dev.to/molly/rake-task-enhance-method-explained-3bo0) Rails'
 `db:create` task so that `test_data` is created along with `development` and
-`test`.
+`test` whenever `rake db:create` is run.
 
 ### test_data:drop_database
 
 This task will drop the `test_data` environment's database if it exists. It also
 enhances Rails' `db:drop` task so that `test_data` is dropped along with
-`development` and `test`.
+`development` and `test` whenever `rake db:drop` is run.
 
 ## API Reference
 
+### TestData.uses_test_data
+
+This is the method designed to be used by your tests to load your test data
+into your `test` database so that your tests can rely on it. Typically, you'll
+want to call it at the beginning of each test that relies on the test data
+managed by this gem—most often, in a before-each hook.
+
+For the sake of speed and integrity, `TestData.uses_test_data` is designed to
+take advantage of nested transactions ([Postgres
+savepoints](https://www.postgresql.org/docs/current/sql-savepoint.html)). By
+default, data is loaded in a transaction and intended to be rolled back to the
+point _immediately after_ the data was imported between tests. This way, your
+test suite only pays the cost of importing the SQL file once, but each of your
+tests can enjoy a clean slate that's free of data pollution from other tests.
+(This is similar to, but separate from, Rails fixtures'
+[use_transactional_tests](https://edgeguides.rubyonrails.org/testing.html#testing-parallel-transactions)
+option.)
+
+_See configuration option:
+[config.after_test_data_load](#configafter_test_data_load)_
+
+### TestData.uses_clean_slate
+
+If a test does not rely on your `test_data` data, you can instead ensure that it
+runs against empty tables by calling `TestData.uses_clean_slate`. Like
+`TestData.uses_test_data`, this would normally be called at the beginning of
+each such test in a before-each hook.
+
+This method works by first ensuring that your test data is loaded (and the
+correspondent savepoint created), then will truncate all affected tables and
+create another savepoint. It's a little counter-intuitive that you'd first
+litter your database with data only to wipe it clean again, but it's much faster
+to repeatedly truncate tables than to repeatedly import large SQL files.
+
+_See configuration options:
+[config.after_test_data_truncate](#configafter_test_data_truncate),
+[config.truncate_these_test_data_tables](#configtruncate_these_test_data_tables)_
+
+### TestData.uses_rails_fixtures
+
+As described in this README's [fixture interop
+guide](#using-test_data-with-rails-fixtures), `TestData.uses_rails_fixtures`
+will load your app's [Rails
+fixtures](https://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures)
+by intercepting Rails' built-in fixture-loading code. As with the other "uses"
+methods, you'll likely want to call it in a before-each hook before any test
+that needs access to your Rails fixtures.
+
+There are two additional things to keep in mind if using this method:
+
+1. Using this feature requires that you've first invoked
+   [TestData.prevent_rails_fixtures_from_loading_automatically!](#testdataprevent_rails_fixtures_from_loading_automatically)
+   to override Rails' default behavior before any of your tests have loaded or
+   started running
+
+2. Because the method depends on Rails' fixture caching mechanism, it must be
+   passed an instance of the running test class (e.g.
+   `TestData.uses_rails_fixtures(self)`)
+
+Under the hood, this method effectively ensures a clean slate the same way
+`TestData.uses_clean_slate` does, except that after creating the truncation
+savepoint, it will then load your fixtures and finally create—wait for it—yet
+another savepoint that subsequent calls to `uses_rails_fixtures` can rollback
+to.
+
+_See configuration option:
+[config.after_rails_fixture_load](#configafter_rails_fixture_load)_
+
+#### TestData.prevent_rails_fixtures_from_loading_automatically!
+
+Call this method before any tests have been loaded or executed by your test
+runner if you're planning to use
+[TestData.uses_rails_fixtures](#testdatauses_rails_fixtures) to load Rails
+fixtures into any of your tests. This method will disable the default behavior
+of loading your Rails fixtures into the test database as soon as the first test
+case with fixtures enabled is executed. (Inspect the [source for the
+patch](/lib/test_data/active_record_ext.rb) to make sure you're comfortable with
+what it's doing.)
+
 ### TestData.config
 
 The generated `config/initializers/test_data.rb` initializer will include a call
 to `TestData.config`, which takes a block that yields a mutable configuration
-object (similar to `Rails.application.config`):
+object (similar to `Rails.application.config`). If anything is unclear after
+reading the documentation, feel free to review the
+[initializer](lib/generators/test_data/initializer_generator.rb) and the [Config
+class](/lib/test_data/config.rb) themselves.
+
+#### Lifecycle hooks
+
+Want to shift forward several timestamp fields after your `test_data` SQL dumps
+are loaded into your test database? Need to refresh a materialized view after
+your Rails fixtures are loaded? You _could_ do these things after calling
+`TestData.uses_test_data` and `TestData.uses_rails_fixtures`, respectively, but
+you'd take the corresponding performance hit in each and every test.
+
+Instead, you can pass a callable or a block and `test_data` will execute it just
+_after_ performing the associated data operation but just _before_ creating a
+transaction savepoint. That way, whenever the gem rolls back between tests, your
+hook won't need to be run again.
+
+##### config.after_test_data_load
+
+This is hook is run immediately after `TestData.uses_test_data` has loaded your
+SQL dumps into the `test` database, but before creating a savepoint. Takes a
+block or anything that responds to `call`.
+
 
 ```ruby
 TestData.config do |config|
-  # Where to store SQL dumps of the test_data database schema
-  # config.schema_dump_path = "test/support/test_data/schema.sql"
-
-  # Where to store SQL dumps of the test_data database test data
-  # config.data_dump_path = "test/support/test_data/data.sql"
+  # Example: roll time forward
+  config.after_test_data_load do
+    Boop.connection.exec_update(<<~SQL, nil, [[nil, Time.zone.now - System.epoch]])
+      update boops set booped_at = booped_at + $1
+    SQL
+  end
+end
+```
 
-  # Where to store SQL dumps of the test_data database non-test data
-  # config.non_test_data_dump_path = "test/support/test_data/non_test_data.sql"
+##### config.after_test_data_truncate
 
-  # Tables whose data shouldn't be loaded into tests.
-  #   ("ar_internal_metadata" and "schema_migrations" are always excluded)
-  # config.non_test_data_tables = []
+This is hook is run immediately after `TestData.uses_clean_slate` has truncated
+your test data, but before creating a savepoint. Takes a block or anything that
+responds to `call`.
 
-  # Tables whose data should be excluded from all dumps (does not affect schema DDL)
-  # config.dont_dump_these_tables = []
+```ruby
+TestData.config do |config|
+  # Example: pass a callable instead of a block
+  config.after_test_data_truncate(SomethingThatRespondsToCall.new)
+end
+```
 
-  # Tables whose data should be truncated by TestData.truncate
-  #   If left as `nil`, all tables inserted into by the SQL file at
-  #   `data_dump_path` will be truncated
-  # config.truncate_these_test_data_tables = nil
+##### config.after_rails_fixture_load
 
-  # Perform TestData.load and TestData.truncate inside nested
-  #   transactions for increased test isolation and speed. Setting this
-  #   to false will disable several features that depend on transactions
-  #   being used
-  # config.use_transactional_data_loader = true
+This is hook is run immediately after `TestData.uses_rails_fixtures` has loaded
+your Rails fixtures into the `test` database, but before creating a savepoint.
+Takes a block or anything that responds to `call`.
 
-  # Log level (valid values: [:debug, :info, :warn, :error, :quiet])
-  # Can also be set with env var TEST_DATA_LOG_LEVEL
-  # config.log_level = :info
+```ruby
+TestData.config do |config|
+  # Example: refresh Postgres assets like materialized views
+  config.after_rails_fixture_load do
+    RefreshesMaterializedViews.new.call
+  end
 end
 ```
 
-### TestData.load
+#### test_data:dump options
 
-This is the method designed to be used by your tests to load your test data
-into your `test` database so that your tests can rely on it.
+The gem provides several options governing the behavior of the
+[test_data:dump](#test_datadump) Rake task. You probably won't need to set these
+unless you run into a problem with the defaults.
 
-#### Loading with the speed & safety of transaction savepoints
+##### config.non_test_data_tables
 
-For the sake of speed and integrity, `TestData.load` is designed to take
-advantage of nested transactions ([Postgres
-savepoints](https://www.postgresql.org/docs/current/sql-savepoint.html)). By
-default, data is loaded in a transaction and intended to be rolled back to the
-point _immediately after_ the data was imported after each test. This way, your
-test suite only pays the cost of importing the SQL file once, but each of your
-tests can enjoy a clean slate that's free of data pollution from other tests.
-(This is similar to, but separate from, Rails fixtures'
-[use_transactional_tests](https://edgeguides.rubyonrails.org/testing.html#testing-parallel-transactions)
-option.)
+Your application may have some tables that are necessary for the operation of
+the application, but irrelevant or incompatible with you your tests. This data
+is still dumped for the sake of being able to restore the database with [rake
+test_data:load](#test_dataload), but will not be loaded when your tests are
+running. Defaults to `[]`, (but will always include `ar_internal_metadata` and
+`schema_migrations`).
 
-To help think through the method's behavior, the method nicknames its
-transactions `:before_data_load` and `:after_data_load`. The first time you call
-`TestData.load`:
-
-1. Creates the `:before_data_load` savepoint
-2. Executes the SQL found in the data dump (e.g.
-   `test/support/test_data/data.sql`) to insert your test data
-3. Creates the `:after_data_load` savepoint
-
-If the method is called and the `:after_data_load` savepoint is already active
-(indicating that the data is loaded), the method rolls back to
-`:after_data_load`, inferring that the user's intention is to have a clean load
-of the test data.
-
-As an additional safeguard, in case a rollback is triggered unexpectedly (i.e.
-calling `rollback_transaction` on `ActiveRecord::Base.connection` instead of via
-`TestData.rollback`), `test_data` writes a memo indicating that the data is
-loaded in `ar_internal_metadata`. `TestData.load` uses this memo to detect this
-issue and will recreate the `:after_data_load` savepoint rather than attempt to
-erroneously reload your SQL data dump. (Similar error-handling is built-into
-[TestData.truncate](#testdatatruncate) and
-[TestData.load_rails_fixtures](#testdataload_rails_fixtures), as well.)
-
-#### Loading without transactions
-
-For most cases, we strongly recommend using the default transactional testing
-strategy, both because it's faster and because it reduces the risk of test
-pollution. However, you may need to commit your test data if the data needs to
-be loaded by multiple processes or over multiple connections.
-
-If you need to load the test data and commit it to the database, simply set
-`TestData.config.use_transactional_data_loader = false`.
-
-If transactions are disabled, you'll need to decide whether and how to clear the
-data out after each test. Many folks use
-[database_cleaner](https://github.com/DatabaseCleaner/database_cleaner) for
-this, while `test_data` offers a rudimentary
-[TestData.truncate](https://github.com/testdouble/test_data#testdatatruncate)
-method that may be sufficient for your needs.
-
-You might imagine something like this if you were loading the data just once for
-the full run of a test suite:
+```ruby
+TestData.config do |config|
+  config.non_test_data_tables = []
+end
+```
+
+##### config.dont_dump_these_tables
+
+Some tables populated by your application may not be necessary to either its
+proper functioning or useful to your tests (e.g. audit logs), so you can save
+time and storage by preventing those tables from being dumped entirely. Defaults
+to `[]`.
 
 ```ruby
-RSpec.configure do |config|
-  config.before :all do
-    TestData.load
-  end
+TestData.config do |config|
+  config.dont_dump_these_tables = []
+end
+```
 
-  config.after :all do
-    TestData.truncate
-  end
+##### config.schema_dump_path
+
+The path to which the schema DDL of your `test_data` database will be written.
+This is only used by [rake test_data:load](#test_dataload) when initializing the
+`test_data` database. Defaults to `"test/support/test_data/schema.sql"`.
+
+```ruby
+TestData.config do |config|
+  config.schema_dump_path = "test/support/test_data/schema.sql"
 end
 ```
 
-Note that when `use_transactional_data_loader` is `false`, subsequent
-`TestData.load` calls won't be able to detect whether the data is already loaded
-and will try to re-insert the data, which will almost certainly result in
-primary key conflicts.
-
-### TestData.rollback
-
-Because the gem loads your data in a transaction, it makes it easy to rollback
-to any of its defined savepoints. In most cases you'll want to roll back to
-`:after_data_load` after each test, and that's what `TestData.rollback` will do
-when called without an argument. If the specified savepoint isn't active,
-calling `rollback` is a no-op.
-
-The gem may create up to four nested savepoints in a single transaction, and
-this method allows you to rollback to any of them. They form the following
-stack:
-
-* `:before_data_load` - Taken before loading your `test_data` dump
-* `:after_data_load` - Taken after loading your `test_data` dump
-* `:after_truncate` - Taken after your `test_data` is truncated
-* `:after_load_rails_fixtures` - Taken after Rails fixtures are loaded via
-  [TestData.load_rails_fixtures](#testdataload_rails_fixtures)
-
-More details on rolling back to each of the gem's savepoints follows below.
-
-#### Rolling back to before test data was loaded
-
-If some tests rely on data loaded by `TestData.load` and you have other tests
-that depend on that data _not being there_, you probably want to call
-[TestData.truncate](#testdatatruncate). But if that won't work for your needs,
-you can rewind to the moment just before your test data was loaded by calling
-`TestData.rollback(:before_data_load)`.
-
-**⚠️ Warning⚠️** Repeatedly loading and rolling back to `:before_data_load` is
-expensive! If your test suite calls `TestData.rollback(:before_data_load)`
-multiple times, it's likely you're re-loading your (possibly large) SQL file of
-test data many more times than is necessary. Consider using
-[TestData.truncate](#testdatatruncate) to achieve the same goal with faster
-performance. Failing that, it might be preferable to partition your test suite
-so that similar tests are run in separate groups (as opposed to in a fully
-random or arbitrary order) to avoid repeatedly thrashing between rollbacks and
-reloads. This partitioning could be accomplished by either configuring your test
-runner or by running separate test commands for each group of tests.
-
-#### Rolling back to after the data was loaded
-
-This is the way you're likely to call this method most often.
-
-When `TestData.rollback` is passed no arguments or called more explicitly as
-`TestData.rollback(:after_data_load)`, the method will rollback to the
-`:after_data_load` transaction savepoint taken immediately after the SQL dump
-was loaded. As a result, it is intended to be run after each test (e.g. in an
-`after(:each)` or `teardown`), to undo any changes made by the test.
-
-#### Rolling back to after test data was truncated
-
-If some of your tests call [TestData.truncate](#testdatatruncate) to clear out
-your test data after it's been loaded (as
-[described](#getting-your-factory-tests-passing-after-adding-test_data) when
-using `test_data` in conjunction with `factory_bot`), then you will likely want
-to run `TestData.rollback(:after_data_truncate)` after each of them. This will
-rewind your test database's state to when those tables were first
-truncated—effectively re-cleaning the slate for the next test.
-
-#### Rolling back to after Rails fixtures were loaded
-
-If you're using
-[TestData.load_rails_fixtures(self)](#testdataload_rails_fixtures) in your
-test's before-each hook, you'll probably want to teardown that test by rolling
-back with `TestData.rollback(:after_load_rails_fixtures)` in an after-each hook,
-which will rewind to the point just after your Rails fixtures were loaded.
-
-### TestData.truncate
-
-Do you have some tests that _shouldn't_ access your test data? Or did some
-existing tests started failing after `test_data` was added? If you want to clear
-the state of your `test` database to support these tests, you can accomplish
-this with `TestData.truncate`. It truncates all the tables that `TestData.load`
-inserted into and then creates a savepoint named `:after_data_truncate`.
-
-Most often, you'll want to call `TestData.truncate` before each test that
-should _not_ have access to your test data created with this gem. After each
-such test, it can clean up by calling `TestData.rollback(:after_data_truncate)`:
+##### config.data_dump_path
+
+The path that the SQL dump of your test data will be written. This is the dump
+that will be executed by `TestData.uses_test_data` in your tests. Defaults to
+`"test/support/test_data/data.sql"`.
 
 ```ruby
-class CleanSlateTest < ActiveDispatch::IntegrationTest
-  def setup do
-    TestData.truncate
-  end
+TestData.config do |config|
+  config.data_dump_path = "test/support/test_data/data.sql"
+end
+```
 
-  def teardown do
-    TestData.rollback(:after_data_truncate)
-  end
+##### config.non_test_data_dump_path
+
+The path to which the [non_test_data_tables](#confignon_test_data_tables) in
+your `test_data` database will be written. This is only used by [rake
+test_data:load](#test_dataload) when initializing the `test_data` database.
+Defaults to `"test/support/test_data/non_test_data.sql"`.
+
+```ruby
+TestData.config do |config|
+  config.non_test_data_dump_path = "test/support/test_data/non_test_data.sql"
 end
 ```
 
-By default, all tables for which there is an `INSERT INTO` statement in your
-test data SQL dump will be truncated (and cascading to any tables with foreign
-keys pointing to those tables), but you can also explicitly specify which tables
-should be truncated yourself by setting the `truncate_these_test_data_tables`
-property on [TestData.config](#testdataconfig) to an array of table names.
+#### Other configuration options
 
-#### If you're not using transactions
+##### config.truncate_these_test_data_tables
 
-Just [like TestData.load](#loading-without-transactions), you can call
-`TestData.truncate` when `use_transactional_data_loader` is `false` and it will
-commit the truncation.
+By default, when [TestData.uses_clean_slate](#testdatauses_clean_slate) is
+called, it will truncate any tables for which an `INSERT` operation was
+detected in your test data SQL dump. This may not be suitable for every case,
+however, so this option allows you to specify which tables are truncated.
+Defaults to `nil`.
 
-### TestData.prevent_rails_fixtures_from_loading_automatically!
+```ruby
+TestData.config do |config|
+  config.truncate_these_test_data_tables = []
+end
+```
 
-Call this method before any tests have been loaded or executed by your test
-runner if you're planning to use
-[TestData.load_rails_fixtures](#testdataload_rails_fixtures) to load Rails
-fixtures into any of your tests. This method will disable the default behavior
-of loading your Rails fixtures into the test database as soon as the first test
-case with fixtures enabled is executed. (Inspect the [source for the
-patch](/lib/test_data/active_record_ext.rb) to make sure you're comfortable with
-what it's doing.)
+##### config.log_level
 
-### TestData.load_rails_fixtures
+The gem outputs its messages to standard output and error by assigning a log
+level to each message. Valid values are `:debug`, `:info`, `:warn`, `:error`,
+`:quiet`. Defaults to `:info`.
 
-As described in this README's [fixture interop
-guide](#getting-your-fixtures-dependent-tests-passing-with-test_data),
-`TestData.load_rails_fixtures` will load your app's [Rails
-fixtures](https://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures)
-into an effectively empty test database inside a nested transaction. Because the
-feature uses Rails built-in fixtures-loading code as well as its caching
-mechanism, the method must be passed an instance of the running test class (in
-a Minitest `setup` hook, that means `TestData.load_rails_fixtures(self)`)
+```ruby
+TestData.config do |config|
+  config.log_level = :info
+end
+```
 
-Using this feature requires that you've:
+### TestData.insert_test_data_dump
 
-1. Invoked
-[TestData.prevent_rails_fixtures_from_loading_automatically!](#testdataprevent_rails_fixtures_from_loading_automatically)
-2. Have `config.use_transactional_data_loader` set to true (the default) in your
-   [config](#testdataconfig)
+If you just want to insert the test data in your application's SQL dumps without
+any of the transaction management or test runner assumptions inherent in
+[TestData.uses_test_data](#testdatauses_test_data), then you can call
+`TestData.insert_test_data_dump` to load and execute the dump.
 
-When you call this method, it will do the following:
+This might be necessary in a few different situations:
 
-1. Verify your `test_data` dump has been loaded (or else load it)
-2. Verify the loaded data has been truncated (or else truncate it)
-3. Load your Rails fixtures from their YAML source files into your test database
-4. Create a new savepoint in the nested transactions named
-   `:after_load_rails_fixtures`
+* Running tests in environments that can't be isolated to a single database
+  transaction (e.g. orchestrating tests across multiple databases, processes,
+  etc.)
+* You might ant to use your test data to seed pre-production environments with
+  enough data to exploratory test (as you might do in a `postdeploy` script with
+  your [Heroku Review
+  Apps](https://devcenter.heroku.com/articles/github-integration-review-apps))
+* Your tests require complex heterogeneous sources of data that aren't a good
+  fit for the assumptions and constraints of this library's default methods for
+  preparing test data
 
-Once loaded, your tests will be able to use your test fixtures inside a
-transaction. At teardown-time, you can reset those fixtures by rolling back with
-[TestData.rollback(:after_load_rails_fixtures)](#rolling-back-to-after-rails-fixtures-were-loaded).
+In any case, since `TestData.insert_test_data_dump` is not wrapped in a
+transaction, when used for automated tests, data cleanup becomes your
+responsibility.
 
 ## Assumptions
 
@@ -1148,12 +1006,11 @@ yet. Here are some existing assumptions and limitations:
 
 If you use `factory_bot` and all of these are true:
 
-* Your integration tests are super fast and not getting significantly slower
+* Your integration tests are super fast and are not getting significantly slower
   over time
 
-* Innocuous changes to factories rarely result in unrelated test failures
-  that—rather than indicating a bug in the production code—instead require that
-  each of those tests be analyzed & updated to get them passing again
+* Minor changes to existing factories rarely result in test failures that
+  require unrelated tests to be read & updated to get them passing again
 
 * The number of associated records generated between your most-used factories
   are representative of production data, as opposed to generating a sprawling
@@ -1169,16 +1026,16 @@ If you use `factory_bot` and all of these are true:
   confidence-eroding nested factories with names like `:user`, `:basic_user`,
   `:lite_user`, and `:plain_user_no_associations_allowed`
 
-If none of these things are true, then congratulations! You are using
-`factory_bot` with great success! Unfortunately, in our experience, this outcome
+If none of these things are true, then congratulations! You are probably using
+`factory_bot` to great effect! Unfortunately, in our experience, this outcome
 is exceedingly rare, especially for large and long-lived applications.
 
-However, if any of the above issues resonate with your experience using
-`factory_bot`: these are the sorts of failure modes the `test_data` gem was
-designed to address. We hope you'll consider trying it with an open mind. At the
-same time, we acknowledge that large test suites can't be rewritten and migrated
-to a different source of test data overnight—nor should they be! See our notes
-on [migrating to `test_data`
+However, if you'd answer "no" to any of the above questions, just know that
+these are the sorts of failure modes the `test_data` gem was designed to
+avoid—and we hope you'll consider trying it with an open mind. At the same time,
+we acknowledge that large test suites can't be rewritten and migrated to a
+different source of test data overnight—nor should they be! See our notes on
+[migrating to `test_data`
 incrementally](#factory--fixture-interoperability-guide)
 
 ### How will I handle merge conflicts in these SQL files if I have lots of people working on lots of feature branches all adding to the `test_data` database dumps?
@@ -1198,13 +1055,13 @@ this risk. The reason that the dumps are stored as plain SQL (aside from the
 fact that git's text compression is very good) is to make merge conflicts with
 other branches feasible, if not entirely painless.
 
-However, if your app is in the very initial stages of development and you're
-making breaking changes to your schema very frequently, our best advice is to
-hold off a bit on writing _any_ integration tests that depend on shared sources
-of test data, as they'll be more likely to frustrate your ability to rapidly
-iterate than detect bugs. Once you you have a reasonably stable feature working
-end-to-end, that's a good moment to start adding integration tests (and thus
-pulling in a test data gem like this one to help you).
+However, if your app is in the very initial stages of development or you're
+otherwise making breaking changes to your schema and data very frequently, our
+best advice is to hold off a bit on writing _any_ integration tests that depend
+on shared sources of test data (regardless of tool), as they'll be more likely
+to frustrate your ability to rapidly iterate than detect bugs. Once you you have
+a reasonably stable feature working end-to-end, that's a good moment to start
+adding integration tests—and perhaps pulling in a gem like this one to help you.
 
 ### Why can't I save multiple database dumps to cover different scenarios?
 
@@ -1220,8 +1077,7 @@ By having a single `test_data` database that grows up with your application just
 like `production` does—with both having their schemas and data migrated
 incrementally over time—your integration tests that depend on `test_data` will
 have an early opportunity to catch bugs that otherwise wouldn't be found until
-they were deployed into a long-lived environment like staging or (gasp!)
-production itself.
+they were deployed into a long-lived staging or (gasp!) production environment.
 
 ### Are you sure I should commit these SQL dumps? They're way too big!
 
@@ -1232,16 +1088,17 @@ cause:
    resetting (or rolling back) your changes and making another attempt at
    generating a more minimal set of test data
 
-2. If certain tables have a lot of records but aren't very relevant to your
-   tests (e.g. audit logs), you might consider either of these options:
+2. If some records persisted by your application aren't very relevant to your
+   tests, you might consider either of these options:
 
-    * Add those tables to the `config.non_test_data_tables` configuration array,
-      where they'd still be committed to git, but won't loaded by your tests
+    * If certain tables are necessary for running the app but aren't needed by
+      your tests, you can add them to the `config.non_test_data_tables`
+      configuration array. They'll still be committed to git, but won't loaded
+      by your tests
 
-    * Exclude data from those tables entirely by adding them to the
-      `config.dont_dump_these_tables` array. (Note that `rake test_data:load`
-      won't be able to restore these tables into your `test_data` environment,
-      so if the data is needed for the app to operate, you'll need to dump them)
+    * If the certain tables are not needed by your application or by your tests
+      (e.g. audit logs), add them to the `config.dont_dump_these_tables` array,
+      and they won't be persisted by `rake test_data:dump`
 
 3. If the dumps are _necessarily_ really big (some apps are complex!), consider
    looking into [git-lfs](https://git-lfs.github.com) for tracking them without
@@ -1264,7 +1121,7 @@ test data loaded from this gem or any other:
 def test_exclude_cancelled_orders
   good_order = Order.new
   bad_order = Order.new(cancelled: true)
-  user = User.create!(orders: good_order, bad_order)
+  user = User.create!(orders: [good_order, bad_order])
 
   result = user.active_orders
 
@@ -1273,17 +1130,18 @@ def test_exclude_cancelled_orders
 end
 ```
 
-This test is simple, self-contained, clearly denotes
-[arrange-act-assert](https://github.com/testdouble/contributing-tests/wiki/Arrange-Act-Assert),
-and (most importantly) will only fail if the functionality stops working.
-Maximizing the number of tests that can be written expressively and succinctly
-without the aid of shared test data is a laudable goal that more teams should
-embrace.
+This test is simple, self-contained, clearly demarcates the
+[arrange-act-assert](https://github.com/testdouble/contributing-tests/wiki/Arrange-Act-Assert)
+phases, and (most importantly) will only fail if the functionality stops
+working. Maximizing the number of tests that can be written expressively and
+succinctly without the aid of shared test data is a laudable goal that more
+teams should embrace.
 
 However, what if the code you're writing doesn't need 3 records in the database,
-but 30? Writing that much test setup would be painstaking and—despite being
-fully-encapsulated—hard for readers to understand what's going on. At that
-point, you have two options:
+but 30? Writing that much test setup would be painstaking, despite being
+fully-encapsulated. Long test setup is harder for others to read and understand.
+And because that setup depends on more of your system's code, it will have more
+reasons to break as your codebase changes. At that point, you have two options:
 
 1. Critically validate your design: why is it so hard to set up? Does it
    _really_ require so much persisted data to exercise this behavior? Would a
@@ -1294,8 +1152,8 @@ point, you have two options:
    [subject](https://github.com/testdouble/contributing-tests/wiki/Subject)
    instead of loading everything from the database? When automated testing is
    saved for the very end of a feature's development, it can feel too costly to
-   reexamine design decisions like this, but it's valuable feedback all the
-   same. *Easy to test code is easy to use code*
+   reexamine design decisions like this, but it can be valuable to consider all
+   the same. *Easy to test code is easy to use code*
 
 2. If the complex setup is a necessary reality of the situation that your app
    needs to handle (and it often will be!), then having _some_ kind of shared
@@ -1304,16 +1162,17 @@ point, you have two options:
 
 As a result, there is no one-size-fits-all approach. Straightforward behavior
 that can be invoked with a clear, concise test has no reason to be coupled to a
-shared source of test data. Subtle behavior that requires lots of
-carefully-arranged data would see its tests grow unwieldy without something to
-help populate that data. So both kinds of test clearly have their place.
+shared source of test data. Meanwhile, tests of more complex behaviors that
+require lots of carefully-arranged data might be unmaintainable without a shared
+source of test data to lean on. So both kinds of test clearly have their place.
 
 But this is a pretty nuanced discussion that can be hard to keep in mind when
 under deadline pressure or on a large team where building consensus around norms
 is challenging. As a result, leaving the decision of which type of test to write
 to spur-of-the-moment judgment is likely to result in inconsistent test design.
 Instead, you might consider separating these two categories into separate test
-types or suites.
+types or suites, with simple heuristics to determine which types of code demand
+which type of test.
 
 For example, it would be completely reasonable to load this gem's test data for
 integration tests, but not for basic tests of models, like so:
@@ -1321,21 +1180,13 @@ integration tests, but not for basic tests of models, like so:
 ```ruby
 class ActionDispatch::IntegrationTest
   setup do
-    TestData.load
-  end
-
-  teardown do
-    TestData.rollback
+    TestData.uses_test_data
   end
 end
 
 class ActiveSupport::TestCase
   setup do
-    TestData.truncate
-  end
-
-  teardown do
-    TestData.rollback(:after_data_truncate)
+    TestData.uses_clean_slate
   end
 end
 ```
@@ -1344,6 +1195,50 @@ In short, this skepticism is generally healthy, and encapsulated tests that
 forego reliance on shared sources of test data should be maximized. For
 everything else, there's `test_data`.
 
+### I'm worried my tests aren't as fast as they should be
+
+The `test_data` gem was written to enable tests that are not only more
+comprehensible and maintainable over the long-term, but also _much faster_ to
+run. That said—and especially if you're adding `test_data` to an existing test
+suite—care should be taken to audit everything the suite does between tests in
+order to optimize its overall runtime.
+
+The first and most likely source of unnecessary slowness is redundant test
+cleanup—the speed gained from sandwiching every expensive operation between
+transaction savepoints can be profound… but can also easily be erased by a
+single before-each hook calling
+[database_cleaner](https://github.com/DatabaseCleaner/database_cleaner) to
+commit a truncation of the database. As a result, it's worth taking a little
+time to take stock of everything that's called between tests during setup &
+teardown to ensure multiple tools aren't attempting to clean up the state of the
+database and potentially interfering with one another.
+
+A second opportunity for optimization is to group tests that use the same type
+of test data together, either into separate suites or by preventing them from
+being run in random order across said types. For example, suppose you have 10
+tests that call `TestData.uses_test_data` and 10 that call
+`TestData.uses_rails_fixtures`. If a test that calls `TestData.uses_test_data`
+is followed by another that calls `uses_test_data`, the only operation needed by
+the second call will be a rollback to the savepoint taken after the test data
+was loaded. If, however, a `uses_test_data` test is followed by a
+`uses_rails_fixtures` test, then the test data will be truncated and the
+fixtures loaded and new savepoints created (which would then be undone again if
+the _next_ test happened to call `uses_test_data`).
+
+As a result of the above, the marginal runtime cost for each `TestData.uses_*`
+method depends on which kinds of test precedes and follows it. That means your
+tests will run faster overall if the tests that call `TestData.uses_test_data`
+are run as a group separately from your tests that rely on
+`TestData.uses_clean_slate` or `TestData.uses_rails_fixtures`. Separating your
+tests into logical groups pretty trivial if you're using RSpec, as the
+[tag](https://relishapp.com/rspec/rspec-core/v/3-10/docs/command-line/tag-option)
+feature was built with this sort of need in mind. If you're using Minitest, you
+might consider organizing the tests in different directories and running
+multiple commands to execute them (e.g. `bin/rails test test/test_data_tests`
+and `bin/rails test/factory_tests`). Every CI configuration is different,
+however, and you may find yourself needing to get creative in configuring things
+to achieve the fastest build time.
+
 ## Code of Conduct
 
 This project follows Test Double's [code of