unreliable 0.1.0 → 0.1.3

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 2df9e50dfb3c9ec6d3775fbb8b0b93c14cacd7d713c9a6eca64a680e4bb7efb6
-  data.tar.gz: 113aaeb8922fb31194e00d1929eb9b6cb6faf1a64890572ff63a343684ad526a
+  metadata.gz: '0081b3f189f7e459a112514a5c35d69bd903fbdc771b6eccd22bb53add828671'
+  data.tar.gz: 0a5c663105b2f774cb64eb464340e36d8c63d393234e0cb855955487800d501f
 SHA512:
-  metadata.gz: 6d436bcdfc0b08cf2dad17b0a5a4c9cda3374eace84ed9c459253f13134d2ffac8450a10fbbad1feed1772b2136ef7046a8293c949a0834e71b2782015f61eb3
-  data.tar.gz: da71c5004921c9328594558338f99b1d94062036281e95d3c991c608c26b3d8e6cbd0a9a66e4c28d7ddfd1dc375ac1ea8f68e60d54bc7f5764986f842f6a3eed
+  metadata.gz: 798bef481aad072fa47730866506a6e040d5b99dea6b71f0af5ca86921380f42713b98182c813f7da2a9a152215e9a2a35a730923f10e3e35c389a5ffa78dd68
+  data.tar.gz: 41d0546cf89f4bb0a2c66e98042fb6f27b4a57391ef7e0e25392a1b0a6eaa14064c6f9bd6e12915a05f8425656a62f794d48ab2ab45f08045b2ad3bfa4e79794

data/CHANGELOG.md

@@ -1,3 +1,15 @@
+## Unreliable 0.1.3 (August 21, 2022) ##
+
+* README and minor gemspec changes.
+
+## Unreliable 0.1.2 (April 27, 2022) ##
+
+* README and internal dependency changes.
+
+## Unreliable 0.1.1 (March 2, 2022) ##
+
+* Internal dependency changes.
+
 ## Unreliable 0.1.0 (March 1, 2022) ##
 
 * Initial release.

data/README.md

@@ -1,42 +1,111 @@
 # Unreliable
 
 ![CI workflow](https://github.com/jamiemccarthy/unreliable/actions/workflows/ci.yml/badge.svg)
-[![Contributor Covenant](https://img.shields.io/badge/Contributor%20Covenant-2.1-4baaaa.svg)](code_of_conduct.md)
+![Gem version](https://img.shields.io/gem/v/unreliable)
+[![Ruby Style Guide](https://img.shields.io/badge/code_style-standard-brightgreen.svg)](https://github.com/testdouble/standard)
+[![Contributor Covenant](https://img.shields.io/badge/Contributor%20Covenant-2.1-4baaaa)](CODE_OF_CONDUCT.md)
 
-Relational databases do not guarantee the order results are returned in, unless an ORDER BY clause makes it unambiguous. However, in practice, they often happen to return the same order most of the time.
+**The `unreliable` gem forces your ActiveRecord tests not to rely on ambiguous ordering. This makes your app and its tests more robust.**
 
-If your Rails code relies on that accidental ordering, that's a bug. And it's a bug that test suites often don't catch. Your tests may be passing accidentally.
+## Installation
 
-In a Rails test environment, Unreliable patches ActiveRecord to always have a final ORDER BY clause that returns results in a random order.
+Add `unreliable` to your `Gemfile`'s `test` group:
 
-With Unreliable installed, every ActiveRecord relation invoked by the test suite will have any ambiguity replaced with randomness. Thus, tests that rely on the ordering of at least two records will typically break at least half the time.
+```ruby
+# Gemfile
 
-If you install Unreliable and your test suite starts failing, but only sometimes, that's your cue to check which relations and scopes your tests are using that you believe to be unambiguously ordered, but actually aren't.
+group :test do
+  gem "unreliable", "~> 0.1"
+end
+```
 
-Unreliable does nothing outside of test environments, and there is intentionally no way to enable Unreliable in any other environment.
+The next time your test suite runs, it may emit new errors and failures. If so, great!
 
-# Implementation
+## The problem with orders
 
-Unreliable patches `ActiveRecord::QueryMethods#build_arel`, the point where an Arel is converted for use, to append an order to the existing order chain. (The patch is applied after ActiveRecord loads, using `ActiveSupport.on_load`, the standard interface since Rails 4.0.)
+Here's an [open secret](#references): **relational databases do not guarantee the order results are returned in, without a thorough `ORDER BY` clause.**
 
-This means that the ORDER BY applies to not just SELECTs but e.g. delete_all and update_all. It also applies within subqueries.
+If all your ActiveRecord ordering is already unambiguous, congratulations! `unreliable` will have no effect.
 
-By always appending the random order, we ensure unreliable ordering for relations that have no order at all, and also for relations with an ambiguous order. For example, ordering by a non-unique column, or a combination of multiple columns which together remain non-unique.
+But sometimes we think we specified an unambiguous order, but didn't. Maybe we ordered on timestamps, which are usually unique but sometimes not. And the test suite will stay silent as long as our database just happens to return the same order.
 
-The patch is only applied when `Rails.env.test?`, and that boolean is also checked on every invocation to make certain it has no effect in any other environment.
+If ambiguous ordering is fine for your app's purposes, but your tests rely on a specific order, that's a bug in your tests. Your tests are incorrectly failing -- rarely -- which can be confusing and annoying.
 
-`Unreliable::Config.disable do ... end` will turn it off for a block.
+Or, if your Rails code relies on that accidental ordering, that's a bug in your app. Your tests are passing when they should be failing.
 
-# Fun trivia
+In both cases, `unreliable` exposes the problem by making those tests fail most of the time.
 
-There are other ways you can order a relation but still have your query be ambiguous!
+## Fixing the new failures
 
-* ORDER BY a column with values that differ only by [character case](https://dev.mysql.com/doc/refman/8.0/en/sorting-rows.html), 
-* ORDER BY values that are identical within the [prefix length limit](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_sort_length) examined for sorting
+When `unreliable` turns up a new test failure, you fix it in one of two ways. Either relax your test so it stops relying on order, or tighten up your app to specify order rigorously. (In my company's app, it was about 50/50.)
 
-`unreliable` correctly tests these because the random order is always appended.
+### Relax a test
+
+Take a look at what your test is checking. If you're testing a method or an endpoint that returns a list whose order doesn't matter, you may have written it to expect the order that was returned the first time you ran it. This often happens with fixtures. You might:
+
+* Make your test accept all correct answers. For example, sort an array in the method's response before comparing.
+
+* Help your test suite focus on what you're testing. If your fixtures' "latest" element could change because they don't specify a timestamp, that might be a distraction that's not relevant to how your app works, so you could assign timestamps to the fixtures.
+
+This makes your test suite more robust.
+
+If your test suite is checking generated `.to_sql` against known-good SQL text, `unreliable` isn't helpful. It's easiest to use `Unreliable::Config.disable { ... }` to turn it off for a block.
+
+### Tighten the app
+
+If your app should be returning results in a particular order, and now with `unreliable` it sometimes does not, your test is correct and your app is wrong. Specify order rigorously in your app.
+
+Maybe you're testing `Book.reverse_chron.first`, and you've defined that ordering this way:
+
+```
+class Book
+  scope :reverse_chron, -> { order(year_published: :desc) }
+end
+```
+
+When you meant to define it unambiguously:
+
+```
+  scope :reverse_chron, -> { order(year_published: :desc, title: :desc) }
+```
+
+Or, if `title` is not unique:
+
+```
+  scope :reverse_chron, -> { order(year_published: :desc, title: :desc, id: :desc) }
+```
+
+The problem in this example is easy to see because many books are published each year. But this error can occur at any time granularity.
+
+## Requirements
+
+`unreliable` is tested to support Ruby 2.6 through 3.1, and Rails 5.0 through 7.0.
 
-# Testing
+As of August 2022, this is all released versions of both that are currently supported, plus several older releases.
+
+`unreliable` depends only on ActiveRecord and Railties. If you have a non-Rails app that uses ActiveRecord, you can still use it.
+
+## Implementation
+
+`unreliable` does exactly nothing outside of test environments. There is intentionally no way to enable `unreliable` in production, and there never will be.
+
+In a Rails test environment, `unreliable` patches ActiveRecord to always append a final `ORDER BY` clause that returns results in a random order.
+
+Because it's appended, the existing ordering is not affected unless it is ambiguous.
+
+With `unreliable` installed, every ActiveRecord relation invoked by the test suite will have any ambiguity replaced with randomness. Tests that rely on the ordering of two records will break half the time. Tests with three or more break most of the time.
+
+`unreliable` patches `ActiveRecord::QueryMethods#build_arel`, the point where an Arel is converted for use, to append an order to the existing order chain. (The patch is applied after ActiveRecord loads, using `ActiveSupport.on_load`, the standard interface since Rails 4.0.) It works with MySQL, Postgres, and SQLite.
+
+This means that the `ORDER BY` applies to not just `SELECT` but e.g. `delete_all` and `update_all`. It also applies within subqueries.
+
+The patch is only applied when `Rails.env.test?`, and that boolean is also checked on every invocation, just to make certain it has no effect in any other environment.
+
+## Contributing
+
+Thoughts and suggestions are welcome. Please read the code of conduct, then create an issue or pull request on GitHub. If you just have questions, go ahead and open an issue, I'm pretty friendly.
+
+### Run the gem's tests
 
 To test locally, against the different versions of ActiveRecord, use Ruby 2.7, the only version currently compatible with all the ActiveRecord versions supported. Install the required gems with:
 
@@ -46,7 +115,13 @@ bundle install
 bundle exec appraisal install
 ```
 
-Then you can run the tests with:
+Run `unreliable`'s linter with:
+
+```
+bundle exec standardrb
+```
+
+Then you can run `unreliable`'s tests with:
 
 ```
 bundle exec appraisal rake
@@ -54,44 +129,62 @@ bundle exec appraisal rake
 
 Appraisal ensures the tests run against every compatible minor version of ActiveRecord.
 
-The GitHub CI workflow in `.github/` ensures those tests are also run against against every compatible minor version of Ruby.
+The GitHub CI workflow in `.github/` ensures those tests are also run against against every compatible minor version of Ruby. Your PR won't trigger my GitHub project's workflow, but you're welcome to run your own, or ask me to run mine manually.
 
-Testing against ActiveRecord is done with [Combustion](https://github.com/pat/combustion), which stands up a local single-table SQLite database and an ActiveRecord-based model for it. This gives us more reliable coverage than mocking unit tests within ActiveRecord itself.
+Testing against ActiveRecord is done with [Combustion](https://github.com/pat/combustion), which stands up a local single-table SQLite database and an ActiveRecord-based model for it. This gives more reliable coverage than mocking unit tests within ActiveRecord itself.
 
-Some initial testing was done against a small but real Rails app locally, which looked like this (I mention this for historical interest only):
+### Experiment
 
+If you'd like to see `unreliable` in action on a small but real Rails app locally, you can do this:
+
+1. In a directory next to your `unreliable` working directory, create a `.ruby-version` of `2.7.6` and a 2-line `Gemfile`: `source "https://rubygems.org"`, `gem "rails", "~> 7.0"`
+2. `bundle install && bundle exec rails new . --force`
+3. `echo 'gem "unreliable", path: "../unreliable"' >> Gemfile`
+4. `bundle install && bundle exec rails generate model post title:string body:text`
+5. `RAILS_ENV=test bundle exec rails db:migrate`
+6. `RAILS_ENV=test bundle exec rails c`
+7. You should see SQLite's `ORDER BY RANDOM()` in ActiveRecord queries:
+
+```
+irb(main):001:0> Post.where(title: "abc")
+   (2.1ms)  SELECT sqlite_version(*)
+  Post Load (0.3ms)  SELECT "posts".* FROM "posts" WHERE "posts"."title" = ? ORDER BY RANDOM()  [["title", "abc"]]
+=> []
+irb(main):002:0> Post.limit(5).delete_all
+  Post Delete All (0.2ms)  DELETE FROM "posts" WHERE "posts"."id" IN (SELECT "posts"."id" FROM "posts" ORDER BY RANDOM() LIMIT ?)  [["LIMIT", 5]]
+=> 0
 ```
-Start with 1-line Gemfile `gem "rails", "~> x.y"`, bundle install, then
 
-$ bundle exec rails new . --skip-javascript --skip-webpack-install --skip-sprockets --skip-turbolinks --skip-jbuilder --skip-spring
+## Ordering trivia
 
-Add to Gemfile test block: gem "unreliable", path: "../unreliable", bundle install again
+The most common ambiguous ordering is an ORDER BY one column that is not unique, like a timestamp.
 
-$ bundle exec rails generate model post title:string body:text
-$ RAILS_ENV=test bundle exec rails db:migrate
-$ RAILS_ENV=test bundle exec rails c
-Loading test environment (Rails 7.0.1)
-3.0.1 :001 > puts Post.where(title: "abc").to_sql
-   (0.7ms)  SELECT sqlite_version(*)
-SELECT "posts".* FROM "posts" WHERE "posts"."title" = 'abc' ORDER BY RAND()
-```
+But there are other ways you can order a relation but still have your query be ambiguous:
+
+* ORDER BY multiple columns, but with no subset which is unique
+* ORDER BY a column with values that differ only by [character case](https://dev.mysql.com/doc/refman/8.0/en/sorting-rows.html)
+* ORDER BY values that are identical within the [prefix length limit](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_sort_length) examined for sorting
+
+`unreliable` correctly tests these because the random order is always appended.
+
+## References
 
-# Development
+SQL standard ([SQL-92](https://web.archive.org/web/20220730144627/https://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt)):
 
-When it's necessary to add new minor versions of ActiveRecord or Ruby, update the Appraisals file and run `bundle exec appraisal update` as well as the install, and update the matrix in the ci.yml workflow.
+> When the ordering of a cursor is partially determined by an _order by clause_, then the relative positions of two rows are determined only by the _order by clause_; if the two rows have equal values for the purpose of evaluating the _order by clause_, then their relative positions are implementation-dependent.
 
-# Contributing
+MySQL ([5.6](https://dev.mysql.com/doc/refman/5.6/en/limit-optimization.html), [5.7](https://dev.mysql.com/doc/refman/5.7/en/limit-optimization.html), [8.0](https://dev.mysql.com/doc/refman/8.0/en/limit-optimization.html)):
 
-Thoughts and suggestions are welcome. Please read the code of conduct, then create an issue or pull request on GitHub.
+> If multiple rows have identical values in the `ORDER BY` columns, the server is free to return those rows in any order, and may do so differently depending on the overall execution plan. In other words, the sort order of those rows is nondeterministic with respect to the nonordered columns.
 
-Future work I'd like to see done includes:
+Postgres ([12](https://www.postgresql.org/docs/12/sql-select.html#SQL-ORDERBY), [13](https://www.postgresql.org/docs/13/sql-select.html#SQL-ORDERBY), [14](https://www.postgresql.org/docs/14/sql-select.html#SQL-ORDERBY)):
 
-* Moving to containerized testing, so the test suite can cover MySQL and Postgres.
+> If two rows are equal according to the leftmost expression, they are compared according to the next expression and so on. If they are equal according to all specified expressions, they are returned in an implementation-dependent order.
 
-* Addressing the deprecation warnings in the test suite for ActiveRecord 5.x. There are two: SQLite 1.3 warning of incompatibility with Ruby 3.2 (which is irrelevant since Rails 5 won't run on Ruby 3.2 and Rails 6 requires SQLite 1.4). And: `DEPRECATION WARNING: Leaving ActiveRecord::ConnectionAdapters::SQLite3Adapter.represent_boolean_as_integer set to false is deprecated.`
+SQLite ([3.39](https://www.sqlite.org/lang_select.html#the_order_by_clause)):
 
-* I'd love to see if there is a way to patch test blocks to run them multiple times with different orders (pk asc, desc, rand). It's hard to see a clean way to do this with a BEGIN/ROLLBACK but maybe it's possible. I doubt there is one simple bottleneck for this in RSpec but I haven't looked into it. By nature this gem makes testing nondeterministic, and if there's a way to actually run queries multiple ways, that would be slower but more comprehensive. On the other hand, if a test suite only defines one fixture item, neither this improvement nor the current state of this gem can catch ordering issues.
+> The order in which two rows for which all ORDER BY expressions evaluate to equal values are returned is undefined.
 
-# See also
+## See also
 
 [chaotic_order](https://rubygems.org/gems/chaotic_order)

data/lib/unreliable/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module Unreliable
-  VERSION = "0.1.0"
+  VERSION = "0.1.3"
 end

data/spec/examples.txt

@@ -1,14 +1,14 @@
 example_id                         | status | run_time        |
 ---------------------------------- | ------ | --------------- |
-./spec/env_spec.rb[1:1]            | passed | 0.00296 seconds |
-./spec/env_spec.rb[1:2]            | passed | 0.00045 seconds |
-./spec/model_select_spec.rb[1:1]   | passed | 0.00056 seconds |
-./spec/model_select_spec.rb[1:2]   | passed | 0.00084 seconds |
-./spec/model_select_spec.rb[1:3]   | passed | 0.00077 seconds |
-./spec/model_select_spec.rb[1:4]   | passed | 0.00077 seconds |
-./spec/model_subquery_spec.rb[1:1] | passed | 0.00145 seconds |
-./spec/model_update_spec.rb[1:1]   | passed | 0.00013 seconds |
-./spec/railtie_spec.rb[1:1]        | passed | 0.00073 seconds |
-./spec/railtie_spec.rb[1:2]        | passed | 0.00019 seconds |
-./spec/version_spec.rb[1:1]        | passed | 0.00128 seconds |
-./spec/version_spec.rb[1:2]        | passed | 0.00015 seconds |
+./spec/env_spec.rb[1:1]            | passed | 0.00261 seconds |
+./spec/env_spec.rb[1:2]            | passed | 0.00042 seconds |
+./spec/model_select_spec.rb[1:1]   | passed | 0.00033 seconds |
+./spec/model_select_spec.rb[1:2]   | passed | 0.0005 seconds  |
+./spec/model_select_spec.rb[1:3]   | passed | 0.00042 seconds |
+./spec/model_select_spec.rb[1:4]   | passed | 0.00064 seconds |
+./spec/model_subquery_spec.rb[1:1] | passed | 0.00135 seconds |
+./spec/model_update_spec.rb[1:1]   | passed | 0.00011 seconds |
+./spec/railtie_spec.rb[1:1]        | passed | 0.00064 seconds |
+./spec/railtie_spec.rb[1:2]        | passed | 0.00014 seconds |
+./spec/version_spec.rb[1:1]        | passed | 0.00116 seconds |
+./spec/version_spec.rb[1:2]        | passed | 0.00016 seconds |

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: unreliable
 version: !ruby/object:Gem::Version
-  version: 0.1.0
+  version: 0.1.3
 platform: ruby
 authors:
 - James McCarthy
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2022-03-02 00:00:00.000000000 Z
+date: 2022-08-21 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: activerecord
@@ -17,6 +17,9 @@ dependencies:
     - - ">="
       - !ruby/object:Gem::Version
         version: '5.0'
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '8.0'
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
@@ -24,6 +27,9 @@ dependencies:
     - - ">="
       - !ruby/object:Gem::Version
         version: '5.0'
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '8.0'
 - !ruby/object:Gem::Dependency
   name: railties
   requirement: !ruby/object:Gem::Requirement
@@ -31,6 +37,9 @@ dependencies:
     - - ">="
       - !ruby/object:Gem::Version
         version: '5.0'
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '8.0'
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
@@ -38,6 +47,9 @@ dependencies:
     - - ">="
       - !ruby/object:Gem::Version
         version: '5.0'
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '8.0'
 - !ruby/object:Gem::Dependency
   name: appraisal
   requirement: !ruby/object:Gem::Requirement
@@ -96,46 +108,18 @@ dependencies:
         version: '13.0'
 - !ruby/object:Gem::Dependency
   name: rspec
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - ">="
-      - !ruby/object:Gem::Version
-        version: '0'
-  type: :development
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - ">="
-      - !ruby/object:Gem::Version
-        version: '0'
-- !ruby/object:Gem::Dependency
-  name: rubocop
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '1.25'
-  type: :development
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '1.25'
-- !ruby/object:Gem::Dependency
-  name: simplecov
   requirement: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: '0.21'
+        version: '3.0'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: '0.21'
+        version: '3.0'
 - !ruby/object:Gem::Dependency
   name: sqlite3
   requirement: !ruby/object:Gem::Requirement
@@ -156,41 +140,28 @@ dependencies:
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: '1.7'
+        version: '1.11'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: '1.7'
+        version: '1.11'
 description: |
   Unreliable helps uncover bugs in Rails apps that rely on ambiguous database ordering.
-  With it installed, a test suite is less likely to accidentally succeed.
+  Installing it makes both your app and your test suite more robust.
 email: jamie@mccarthy.vg
 executables: []
 extensions: []
 extra_rdoc_files: []
 files:
-- Appraisals
 - CHANGELOG.md
 - CODE_OF_CONDUCT.md
 - Gemfile
 - LICENSE
 - README.md
 - Rakefile
-- gemfiles/activerecord_5.0.gemfile
-- gemfiles/activerecord_5.0.gemfile.lock
-- gemfiles/activerecord_5.1.gemfile
-- gemfiles/activerecord_5.1.gemfile.lock
-- gemfiles/activerecord_5.2.gemfile
-- gemfiles/activerecord_5.2.gemfile.lock
-- gemfiles/activerecord_6.0.gemfile
-- gemfiles/activerecord_6.0.gemfile.lock
-- gemfiles/activerecord_6.1.gemfile
-- gemfiles/activerecord_6.1.gemfile.lock
-- gemfiles/activerecord_7.0.gemfile
-- gemfiles/activerecord_7.0.gemfile.lock
 - lib/unreliable.rb
 - lib/unreliable/build_order.rb
 - lib/unreliable/config.rb
@@ -228,5 +199,5 @@ requirements: []
 rubygems_version: 3.1.6
 signing_key: 
 specification_version: 4
-summary: Randomize relation final order for tests
+summary: For ActiveRecord tests, surface ambiguous-ordering bugs
 test_files: []

data/Appraisals

@@ -1,32 +0,0 @@
-# frozen_string_literal: true
-
-# The appraisal gem seems to be a convenient way to use this small config file to
-# build the gemfiles/* for the GitHub CI matrix.
-# Any `bundle update/install` should be accompanied by `bundle exec appraisal update/install`
-
-appraise "activerecord-5.0" do
-  gem "activerecord", "~> 5.0.0"
-  gem "sqlite3", "~> 1.3.6"
-end
-
-appraise "activerecord-5.1" do
-  gem "activerecord", "~> 5.1.0"
-  gem "sqlite3", "~> 1.3.6"
-end
-
-appraise "activerecord-5.2" do
-  gem "activerecord", "~> 5.2.0"
-  gem "sqlite3", "~> 1.3.6"
-end
-
-appraise "activerecord-6.0" do
-  gem "activerecord", "~> 6.0.0"
-end
-
-appraise "activerecord-6.1" do
-  gem "activerecord", "~> 6.1.0"
-end
-
-appraise "activerecord-7.0" do
-  gem "activerecord", "~> 7.0.0"
-end

data/gemfiles/activerecord_5.0.gemfile

@@ -1,8 +0,0 @@
-# This file was generated by Appraisal
-
-source "https://rubygems.org"
-
-gem "activerecord", "~> 5.0.0"
-gem "sqlite3", "~> 1.3.6"
-
-gemspec path: "../"

data/gemfiles/activerecord_5.0.gemfile.lock

@@ -1,143 +0,0 @@
-PATH
-  remote: ..
-  specs:
-    unreliable (0.1.0)
-      activerecord (>= 5.0)
-      railties (>= 5.0)
-
-GEM
-  remote: https://rubygems.org/
-  specs:
-    actionpack (5.0.7.2)
-      actionview (= 5.0.7.2)
-      activesupport (= 5.0.7.2)
-      rack (~> 2.0)
-      rack-test (~> 0.6.3)
-      rails-dom-testing (~> 2.0)
-      rails-html-sanitizer (~> 1.0, >= 1.0.2)
-    actionview (5.0.7.2)
-      activesupport (= 5.0.7.2)
-      builder (~> 3.1)
-      erubis (~> 2.7.0)
-      rails-dom-testing (~> 2.0)
-      rails-html-sanitizer (~> 1.0, >= 1.0.3)
-    activemodel (5.0.7.2)
-      activesupport (= 5.0.7.2)
-    activerecord (5.0.7.2)
-      activemodel (= 5.0.7.2)
-      activesupport (= 5.0.7.2)
-      arel (~> 7.0)
-    activesupport (5.0.7.2)
-      concurrent-ruby (~> 1.0, >= 1.0.2)
-      i18n (>= 0.7, < 2)
-      minitest (~> 5.1)
-      tzinfo (~> 1.1)
-    appraisal (2.4.1)
-      bundler
-      rake
-      thor (>= 0.14.0)
-    arel (7.1.4)
-    ast (2.4.2)
-    builder (3.2.4)
-    combustion (1.3.5)
-      activesupport (>= 3.0.0)
-      railties (>= 3.0.0)
-      thor (>= 0.14.6)
-    concurrent-ruby (1.1.9)
-    crass (1.0.6)
-    diff-lcs (1.5.0)
-    docile (1.4.0)
-    erubis (2.7.0)
-    i18n (1.10.0)
-      concurrent-ruby (~> 1.0)
-    loofah (2.14.0)
-      crass (~> 1.0.2)
-      nokogiri (>= 1.5.9)
-    method_source (1.0.0)
-    minitest (5.15.0)
-    nokogiri (1.13.3-x86_64-linux)
-      racc (~> 1.4)
-    parallel (1.21.0)
-    parser (3.1.1.0)
-      ast (~> 2.4.1)
-    racc (1.6.0)
-    rack (2.2.3)
-    rack-test (0.6.3)
-      rack (>= 1.0)
-    rails-dom-testing (2.0.3)
-      activesupport (>= 4.2.0)
-      nokogiri (>= 1.6)
-    rails-html-sanitizer (1.4.2)
-      loofah (~> 2.3)
-    railties (5.0.7.2)
-      actionpack (= 5.0.7.2)
-      activesupport (= 5.0.7.2)
-      method_source
-      rake (>= 0.8.7)
-      thor (>= 0.18.1, < 2.0)
-    rainbow (3.1.1)
-    rake (13.0.6)
-    regexp_parser (2.2.1)
-    rexml (3.2.5)
-    rspec (3.11.0)
-      rspec-core (~> 3.11.0)
-      rspec-expectations (~> 3.11.0)
-      rspec-mocks (~> 3.11.0)
-    rspec-core (3.11.0)
-      rspec-support (~> 3.11.0)
-    rspec-expectations (3.11.0)
-      diff-lcs (>= 1.2.0, < 2.0)
-      rspec-support (~> 3.11.0)
-    rspec-mocks (3.11.0)
-      diff-lcs (>= 1.2.0, < 2.0)
-      rspec-support (~> 3.11.0)
-    rspec-support (3.11.0)
-    rubocop (1.25.1)
-      parallel (~> 1.10)
-      parser (>= 3.1.0.0)
-      rainbow (>= 2.2.2, < 4.0)
-      regexp_parser (>= 1.8, < 3.0)
-      rexml
-      rubocop-ast (>= 1.15.1, < 2.0)
-      ruby-progressbar (~> 1.7)
-      unicode-display_width (>= 1.4.0, < 3.0)
-    rubocop-ast (1.16.0)
-      parser (>= 3.1.1.0)
-    rubocop-performance (1.13.2)
-      rubocop (>= 1.7.0, < 2.0)
-      rubocop-ast (>= 0.4.0)
-    ruby-progressbar (1.11.0)
-    simplecov (0.21.2)
-      docile (~> 1.1)
-      simplecov-html (~> 0.11)
-      simplecov_json_formatter (~> 0.1)
-    simplecov-html (0.12.3)
-    simplecov_json_formatter (0.1.4)
-    sqlite3 (1.3.13)
-    standard (1.7.2)
-      rubocop (= 1.25.1)
-      rubocop-performance (= 1.13.2)
-    thor (1.2.1)
-    thread_safe (0.3.6)
-    tzinfo (1.2.9)
-      thread_safe (~> 0.1)
-    unicode-display_width (2.1.0)
-
-PLATFORMS
-  x86_64-linux
-
-DEPENDENCIES
-  activerecord (~> 5.0.0)
-  appraisal (~> 2.4)
-  bundler (~> 2.1)
-  combustion (~> 1.3)
-  rake (~> 13.0)
-  rspec
-  rubocop (~> 1.25)
-  simplecov (~> 0.21)
-  sqlite3 (~> 1.3.6)
-  standard (~> 1.7)
-  unreliable!
-
-BUNDLED WITH
-   2.3.8

data/gemfiles/activerecord_5.1.gemfile

@@ -1,8 +0,0 @@
-# This file was generated by Appraisal
-
-source "https://rubygems.org"
-
-gem "activerecord", "~> 5.1.0"
-gem "sqlite3", "~> 1.3.6"
-
-gemspec path: "../"