Automatically maintain test database schema

[jonleighton]

• Move check from generated helper to test_help.rb, so that all
  applications can benefit
• Rather than just raising when the test schema has pending migrations,
  try to load in the schema and only raise if there are pending
  migrations afterwards

TODO:

• We no longer need db:test:prepare and friends. Deprecate them.
• Update docs/changelog
• Add config option to allow users to opt-out of this behaviour

[josevalim]

Great work. If we are going to allow people to manually opt-out of this behaviour we should probably not remove db:test:prepare for the users that would prefer to do it manually. Or would they rather call load_schema_if_pending?

[jonleighton]

@josevalim I'm basically proposing we deprecate these: https://github.com/rails/rails/blob/master/activerecord/lib/active_record/railties/databases.rake#L301-L364

I don't see what purpose they serve any more. People who want to do these things manually can do stuff like

rake db:schema:load RAILS_ENV=test

So I don't think we need these test-specific rake tasks at all?

[josevalim]

Sounds good!

[jonleighton]

@josevalim I consider this finished now, let me know if you have any more comments

[rafaelfranca]

Seems good to me

[jonleighton]

cc @alindeman in case you want to add this to rspec-rails

[schneems]

❤️ great work here.

[jasontorres]

Great job!

[orendon]

👍

[tamouse]

this makes me weep with joy

[jaredbeck]

Should rspec users add require 'rails/test_help' to their spec_helper? Thanks, looking forward to trying this out!

[jonleighton]

@jaredbeck yep could do, but I think ideally the rspec-rails gem would integrate support for this

[swebb]

@jaredbeck I found adding require 'rails/test_help' caused rspec and minitest to run. Instead I added ActiveRecord::Migration.maintain_test_schema! to my spec_helper.

[jaredbeck]

I think ideally the rspec-rails gem would integrate support for this

If I'm understanding rspec/rspec-rails#946 correctly, newly-generated spec_helper files will include a call to maintain_test_schema!. Is that what you were thinking, Jon?

[kevintyll]

The only problem with removing the test load tasks, is that they purge the db before loading it, so now deleted tables will never be removed from the test db.

A separate issue is we are constantly branching and merging our app, so using the latest schema info to determine if we need to load the schema does not work for us. I may be switching to a branch that has a later migration than the one I just came from, but it won't load because the test db has a more recent migration. I'm solving the problem by comparing the structure.sql mtime to the test.log mtime.

Here is the patch file I created for our use. I don't think this is a global solution, but it works for us and may give you ideas if you agree that using the schema_migrations table is limited. The path file also includes patches for parallel_test, which adds additional issues:

# As of rails 4.1, the schema is loaded automatically if needed based on the schema_migrations table, the problem with this is
# with migrations created in different branches, that not very accurate.  This file overrides the classes necessary
# to load it based on comparing the structure.sql modified time and the test.log modified time.  It will load if the structure
# was modified since the last test run.

# This file also overrides the structure load task to do a purge before loading.


# This file gets loaded in the test and development environments from application.rb

if Rails.env.test?
  module ActiveRecord
    module Tasks # :nodoc:
      module DatabaseTasks
        # structure_load does not purge the db first, so deleted tables do not get deleted.
        # this gets called automatically from tests as of rails 4.1.0
        def structure_load_with_purge(*arguments)
          puts "Loading structure.sql"
          purge(current_config)
          structure_load_without_purge(*arguments)
          ActiveRecord::Migrator.last_test_run = Time.now
        end

        alias_method_chain :structure_load, :purge
      end
    end
  end

  module ActiveRecord
    class Migrator #:nodoc:
      class << self

        cattr_accessor :last_test_run

        def needs_migration?(connection = Base.connection)
          structure_updated = File.mtime('db/structure.sql')
          puts "Structure.sql modified: #{structure_updated}"
          puts "Last test run: #{last_test_run}"
          last_test_run < structure_updated
        end
      end
    end
  end


  Rails.application.config.before_configuration do
    # If running parallel tests, one process may get ahead of the others and write to the test.log file before another process can
    # check it to see if the structure should be loaded.  So some instances may load the structure, but not others.
    # Have all processes wait here until all have started so they can check the log file at the same time.
    if ENV['PARALLEL_TEST_GROUPS'].present?
      loop do
        break if ParallelTests.number_of_running_processes.to_s == ENV['PARALLEL_TEST_GROUPS'].to_s
        sleep 1
      end
    end
    ActiveRecord::Migrator.last_test_run = File.mtime('log/test.log') rescue Time.parse('2009-01-01')
  end
end

if Rails.env.development?
  require 'parallel_tests/tasks'
  module ParallelTests
    module Tasks
      class << self
        def check_for_pending_migrations
          # no op
          # we just want to load the structure file, we don't care if the dev db has not run all the migrations yet.
          # if the structure file is missing migrations, it will still error as of rails 4.1
        end
      end
    end
  end
end

[JuanitoFatas]

How to remove the WARNING?

WARNING: db:test:prepare is deprecated. The Rails test helper now maintains your test schema automatically, see the release notes for details.

Do not use rake db:test:prepare ? Thanks.

[rafaelfranca]

Yes. it should not be used anymore.

[JuanitoFatas]

Thank you @rafaelfranca.

[mediafinger]

Thx for deprecating rake db:test:prepare! ❤️

[talsafran]

If I create a migration and migrate it:

class CreateCookPhotos < ActiveRecord::Migration
  def change
    create_table :cook_photos do |t|
      t.integer :cook_id
      t.string :url

      t.timestamps
    end
  end
end

And then roll it back because I want to add or change something in the migration (say change the name of the url column to filename)

Then the test database doesn't seem to catch the change.

To alleviate this, I have to:

rake db:rollback RAILS_ENV=test
rake db:migrate RAILS_ENV=test

This is more work than just copying the schema over with something like rake db:test:prepare. Anything I could do to simplify this?

[spastorino]

seems like a ActiveRecord::Tasks::DatabaseTasks.purge is missing here. /cc @jonleighton. See #15787 Is what we were doing under test namespace

[spastorino]

So seems like it's already fixed #15394

[GeekOnCoffee]

Any suggestions on how to hook into this behavior? I've read through it a few times looking for a good integration point but haven't found anywhere... looking to reseed when the test database is rebuilt, as we have seed data that's required for tests to pass

[curtislinden]

I'm wondering on the status of this? I'm looking for a way to maintain a test rails env that isn't called 'test'