test_data 0.2.2 → 0.3.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 18d3469e9d0173f81ef3b2d8d082861094d79354b8fb544e983bdcfdd8eb788b
-  data.tar.gz: 983a1645132b22024799670ec463f11fe5f8e0d1b9427b96940dea8c684fbafb
+  metadata.gz: 9e046c25f181fc9022139cd1d009142b390d7da348d9eb00dc18f03291927c35
+  data.tar.gz: 60dfa3ca0fbbf8389d009ceec584f2239eb01391c2e3fb88badd063669c48d28
 SHA512:
-  metadata.gz: c7fb1b86f23f074bb185cb1cf11c437d4ba57445d65907509384838993628c5759803ee90f3f290dbb219754806bb1c1133b7e84bf430918c1a23b3fca86b752
-  data.tar.gz: d00e512b415c74ab1650a3b3d58e36759d085056375e07326d8790d0033bc18066a2d82c791a578fb9d11cb7c08f9056d4d5e380b9cc52f97dd467c245469771
+  metadata.gz: 5d3727bbd0f8bf7cb3d32c042864a624c0cf5ebcd956f7abf158aeb0cabbbc97505a4c18b5f4345a8ea4570d56384532f2ecfeed03d1319850f92a61602ecb63
+  data.tar.gz: dab23d60d8c459bc756e532e35e7de0e499a3b760a1f3ec652d5aea866503b6ccdac670edcc0bba0fafc1cc4f7c3281b98b21760ce84b808d5c5428b25f1d64b

data/CHANGELOG.md

@@ -1,3 +1,22 @@
+# 0.3.2
+
+- Improve the flexibility of the webpacker config generator
+- Improve failure output when an error is raised during rake tests that fork
+  into a `test_data` env
+
+# 0.3.1
+
+- Loosen railties dependencies after verifying basic Rails 7 support
+
+# 0.3.0
+
+- Add a `test_data:reinitialize` task that will delete the `test_data` database
+  if necessary before invoking `test_data:initialize`
+  - Warn if re-initializing and the local database appears to have been dumped
+    or loaded from a dump that is newer than the dumps on disk
+- Add a warning on app load if the dumps on disk appear
+  newer than the local `test_data` database
+
 # 0.2.2
 
 - Improve performance of Rails fixtures being repeatedly loaded by changing the

data/Gemfile.lock

@@ -1,96 +1,96 @@
 PATH
   remote: .
   specs:
-    test_data (0.2.2)
-      railties (~> 6.0)
+    test_data (0.3.2)
+      railties (>= 6.0, < 8.0)
 
 GEM
   remote: https://rubygems.org/
   specs:
-    actionpack (6.1.4)
-      actionview (= 6.1.4)
-      activesupport (= 6.1.4)
-      rack (~> 2.0, >= 2.0.9)
+    actionpack (7.0.2.3)
+      actionview (= 7.0.2.3)
+      activesupport (= 7.0.2.3)
+      rack (~> 2.0, >= 2.2.0)
       rack-test (>= 0.6.3)
       rails-dom-testing (~> 2.0)
       rails-html-sanitizer (~> 1.0, >= 1.2.0)
-    actionview (6.1.4)
-      activesupport (= 6.1.4)
+    actionview (7.0.2.3)
+      activesupport (= 7.0.2.3)
       builder (~> 3.1)
       erubi (~> 1.4)
       rails-dom-testing (~> 2.0)
       rails-html-sanitizer (~> 1.1, >= 1.2.0)
-    activesupport (6.1.4)
+    activesupport (7.0.2.3)
       concurrent-ruby (~> 1.0, >= 1.0.2)
       i18n (>= 1.6, < 2)
       minitest (>= 5.1)
       tzinfo (~> 2.0)
-      zeitwerk (~> 2.3)
     ast (2.4.2)
     builder (3.2.4)
     coderay (1.1.3)
-    concurrent-ruby (1.1.9)
+    concurrent-ruby (1.1.10)
     crass (1.0.6)
     erubi (1.10.0)
-    i18n (1.8.10)
+    i18n (1.10.0)
       concurrent-ruby (~> 1.0)
-    loofah (2.11.0)
+    loofah (2.16.0)
       crass (~> 1.0.2)
       nokogiri (>= 1.5.9)
     method_source (1.0.0)
-    mini_portile2 (2.6.1)
-    minitest (5.14.4)
-    nokogiri (1.12.0)
-      mini_portile2 (~> 2.6.1)
+    mini_portile2 (2.8.0)
+    minitest (5.15.0)
+    nokogiri (1.13.3)
+      mini_portile2 (~> 2.8.0)
       racc (~> 1.4)
-    parallel (1.20.1)
-    parser (3.0.1.0)
+    parallel (1.22.1)
+    parser (3.1.1.0)
       ast (~> 2.4.1)
     pry (0.14.1)
       coderay (~> 1.1)
       method_source (~> 1.0)
-    racc (1.5.2)
+    racc (1.6.0)
     rack (2.2.3)
     rack-test (1.1.0)
       rack (>= 1.0, < 3)
     rails-dom-testing (2.0.3)
       activesupport (>= 4.2.0)
       nokogiri (>= 1.6)
-    rails-html-sanitizer (1.3.0)
+    rails-html-sanitizer (1.4.2)
       loofah (~> 2.3)
-    railties (6.1.4)
-      actionpack (= 6.1.4)
-      activesupport (= 6.1.4)
+    railties (7.0.2.3)
+      actionpack (= 7.0.2.3)
+      activesupport (= 7.0.2.3)
       method_source
-      rake (>= 0.13)
+      rake (>= 12.2)
       thor (~> 1.0)
-    rainbow (3.0.0)
-    rake (13.0.3)
-    regexp_parser (2.1.1)
+      zeitwerk (~> 2.5)
+    rainbow (3.1.1)
+    rake (13.0.6)
+    regexp_parser (2.3.0)
     rexml (3.2.5)
-    rubocop (1.12.1)
+    rubocop (1.26.1)
       parallel (~> 1.10)
-      parser (>= 3.0.0.0)
+      parser (>= 3.1.0.0)
       rainbow (>= 2.2.2, < 4.0)
       regexp_parser (>= 1.8, < 3.0)
       rexml
-      rubocop-ast (>= 1.2.0, < 2.0)
+      rubocop-ast (>= 1.16.0, < 2.0)
       ruby-progressbar (~> 1.7)
       unicode-display_width (>= 1.4.0, < 3.0)
-    rubocop-ast (1.4.1)
-      parser (>= 2.7.1.5)
-    rubocop-performance (1.10.1)
-      rubocop (>= 0.90.0, < 2.0)
+    rubocop-ast (1.17.0)
+      parser (>= 3.1.1.0)
+    rubocop-performance (1.13.3)
+      rubocop (>= 1.7.0, < 2.0)
       rubocop-ast (>= 0.4.0)
     ruby-progressbar (1.11.0)
-    standard (1.0.5)
-      rubocop (= 1.12.1)
-      rubocop-performance (= 1.10.1)
-    thor (1.1.0)
+    standard (1.9.1)
+      rubocop (= 1.26.1)
+      rubocop-performance (= 1.13.3)
+    thor (1.2.1)
     tzinfo (2.0.4)
       concurrent-ruby (~> 1.0)
-    unicode-display_width (2.0.0)
-    zeitwerk (2.4.2)
+    unicode-display_width (2.1.0)
+    zeitwerk (2.5.4)
 
 PLATFORMS
   ruby
@@ -103,4 +103,4 @@ DEPENDENCIES
   test_data!
 
 BUNDLED WITH
-   2.2.15
+   2.3.10

data/LICENSE.txt

@@ -1,4 +1,4 @@
-Copyright (c) 2021 Test Double, LLC
+Copyright (c) 2021 Test Double, Inc.
 
 Permission is hereby granted, free of charge, to any person obtaining
 a copy of this software and associated documentation files (the

data/README.md

@@ -19,8 +19,8 @@ What it does:
   app**
 
 * 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
+  your tests, whether the test depends on test_data, factories, fixtures, or an
+  empty database
 
 * Safeguards your tests from flaky failures and supercharges your build by
   providing a sophisticated transaction manager that isolates each test while
@@ -41,11 +41,11 @@ are required**—so it may not work for every project just yet.]_
 
 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 be _unnecessary complexity_ but
-instead be an indication of how little of the problem's _essential complexity_
-we have reckoned with to this point.
+there's one reason Rails apps often suffer from slow tests, it's that the most
+popular approaches to test data management oversimplify the problem—they might
+save time up front, but tend to cost you later. The `test_data` gem, meanwhile,
+is designed to tackle the problem head on: it takes longer to set up, but it'll
+scale along with your application for years to come.
 
 1. [Getting Started Guide](#getting-started-guide)
     1. [Install and initialize `test_data`](#step-1-install-and-initialize-test_data)
@@ -61,6 +61,7 @@ we have reckoned with to this point.
     * [test_data:configure](#test_dataconfigure)
     * [test_data:verify_config](#test_dataverify_config)
     * [test_data:initialize](#test_datainitialize)
+    * [test_data:reinitialize](#test_datareinitialize)
     * [test_data:dump](#test_datadump)
     * [test_data:load](#test_dataload)
     * [test_data:create_database](#test_datacreate_database)
@@ -105,22 +106,42 @@ And if you get stuck or need help as you're getting started, please feel free to
 
 ### Step 1: Install and initialize `test_data`
 
-#### Adding the gem
+#### Adding a `:test_data` group to your Gemfile
+
+Before even installing anything, it's important to understand that because
+`test_data` defines a new Rails environment and because Rails expects
+a gem group (like `:development`, `:test`, and `:production`) for each
+environment, any gems we want to be available to the `test_data` gem need to be
+installed with a `:test_data` group.
+
+Since the `test_data` environment is designed to be used similarly to
+`development` (i.e. with a running server and interacting via a browser), any
+gems in your `:development` gem group should likely be included in a
+`:test_data` gem group as well.
 
-First, add `test_data` to your Gemfile. Either include it in all groups or add
-it to the `:development`, `:test`, and (the all new!) `:test_data` gem groups:
+For example, this:
 
 ```ruby
-group :development, :test, :test_data do
+group :development, :test do
+  gem "standard"
+  gem "cypress-rails"
   gem "test_data"
-  # … other gems available to development & test
 end
 ```
 
-Since the `test_data` environment is designed to be used similarly to
-`development` (i.e. with a running server and interacting via a browser), any
-gems in your `:development` gem group should likely be included in a
-`:test_data` gem group as well.
+Should have its first line changed to:
+
+```ruby
+group :development, :test, :test_data do
+```
+
+#### Adding the gem
+
+Finally, add `test_data` to your Gemfile and `bundle install` it:
+
+```ruby
+gem "test_data"
+```
 
 #### Configuring the gem and initializing the database
 
@@ -430,23 +451,21 @@ to update your test data. Here's how to do it:
     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. Run `rake test_data:drop_database`
-
-    3. Run `rake test_data:load` to recreate the `test_data` database and load
-       the latest SQL dumps into it
+    2. Run `rake test_data:reinitialize` drop and recreate the `test_data`
+       database and load the latest SQL dumps into it
 
-    4. Run any pending migrations with `RAILS_ENV=test_data bin/rake db:migrate`
+    3. Run any pending migrations with `RAILS_ENV=test_data bin/rake db:migrate`
 
-    5. If you need to create any additional data, start up the server
+    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)
 
-    6. Export your newly-updated `test_data` database with `rake test_data:dump`
+    5. 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
+    6. 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
+  dumps, follow steps **3 through 6** 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`
@@ -664,6 +683,18 @@ your seed file. Specifically:
     * Otherwise, it invokes the task `db:schema:load` and `db:seed` (similar to
       Rails' built-in `db:setup` task)
 
+### test_data:reinitialize
+
+This task is designed for the situation where you may already have a `test_data`
+database created and simply want to drop it and replace it with whatever dumps
+are in the `test/support/test_data` directory.
+
+Dropping the database requires confirmation, either interactively or by setting
+the environment variable `TEST_DATA_CONFIRM`. It will additionally warn you in
+the event that the local database appears to be newer than the dumps on disk
+that would replace it. From there, this task behaves the same way as `rake
+test_data:initialize`.
+
 ### test_data:dump
 
 This task is designed to be run after you've created or updated your test data
@@ -775,8 +806,8 @@ 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
+   before your tests have started running 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.
@@ -1227,20 +1258,9 @@ result in a significantly slower overall test suite. Instead, if you group tests
 that use the same type of test data together (e.g. by separating them into
 separate suites), you might find profound speed gains.
 
-To illustrate why, suppose you have 5 tests that call `TestData.uses_test_data`
-and 5 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 a lot more work is required:
-first a rollback, then the truncation of the test data, then a load of the
-fixtures followed by creation of a new savepoint—which would in tunr be undone
-again if the _next_ test happened to call `uses_test_data`. Switching between
-tests that use different sources of test data can cause significant unnecessary
-thrashing.
-
-To illustrate the above, if all of these tests ran in random order (the
-default), you might see:
+To illustrate this, suppose you had 5 tests that relied on your `test_data` data
+and 5 that relied on Rails fixtures. If all of these tests ran in random order
+(the default), you might see the following behavior at run-time:
 
 ```
 $ bin/rails test test/example_test.rb
@@ -1272,9 +1292,11 @@ data into sub-suites that are run serially, on e after the other.
   [minitest-suite](https://github.com/testdouble/minitest-suite) to accomplish
   exactly this. Just declare something like `suite :test_data` or `suite
   :fixtures` at the top of each test class
-* If you're using RSpec, the
-  [tag](https://relishapp.com/rspec/rspec-core/v/3-10/docs/command-line/tag-option)
-  feature can help you organize your tests by type, but you'll likely have to
+* If you're using RSpec, the [suite option combined with a custom
+  ordering](https://gist.github.com/myronmarston/8fea012b9eb21b637335bb29069bce6b)
+  can accomplish this. You might also consider using
+  [tags](https://relishapp.com/rspec/rspec-core/v/3-10/docs/command-line/tag-option)
+  to organize your tests by type, but you'll likely have to
   run a separate CLI invocation for each to avoid the tests from being
   interleaved