Hello,
I need to load the seeds.rb into my test environment in order to test the controllers.
I just added:
require "#{Rails.root}/db/seeds.rb"
to test_helper.rb
But, of course, it's seeding the data whenever I test something. The seeds.rb is quite big and takes about 2 minutes to load so when I test one single file it's taking quite a lot of time to load the seed.
Can I somehow prevent truncating the data and seeding the data every time I test?
Is there any command to copy the development database to the test database? Not the schema, the database itself.
Heinz Strunk wrote:
Is there any command to copy the development database to the test database? Not the schema, the database itself.
This is a really BAD idea. Don't do it!
Instead use Machinist or something like it:
Well, I meant the data from seeds.rb which is not loaded in the test environment by default. I just db:seed RAILS_ENV=test and commented fixtures :all out so the seed doesn't get overridden.
Heinz Strunk wrote:
Well, I meant the data from seeds.rb which is not loaded in the test environment by default. I just db:seed RAILS_ENV=test and commented fixtures :all out so the seed doesn't get overridden.
As I said, This is a VERY BAD idea. One of the primary rules of testing is to reset your test database between each and every test that runs. You want to start each test (or spec) in a "known state."
This is why fixtures work the way they do. But, fixtures are a complete pain to deal with. Machinist is a test data factory framework that is much more maintainable, and sane, than using fixtures.
Take the time to read though the docs of the Machinist Github page. And, read up on how to do proper unit testing and you'll see the error of your ways.
I know what you mean but it really sucks to wait up to 2 mins. to run every single test... what else can I do to speed it up?
Heinz Strunk wrote:
I know what you mean but it really sucks to wait up to 2 mins. to run every single test... what else can I do to speed it up?
Don't run every single test every time. Use something like autotest to run just the tests specific to the files you're changing as you code. This is just one approach.
What you don't want to do is compromise the integrity of your testing environment for the sake of making them faster. Fast and wrong is worse than slow and reliable.
Another way to drastically improve performance is to make sure you only touch the database for tests that absolutely must. Get aquatinted with a good mocking and stubbing framework, whether that be the one built into RSpec, or a dedicated one like Mocha. If you can perform your test with a new (unsaved) object then do so.
When all this becomes too much to handle effectively, then it might be time to look into a Continuous Integration (CI) system, where the test run on a server (or set of servers) and reports back to you when you break something.
Point is that there are many options for improving your testing environment's performance without compromising the quality of your testing (as will happen if you did what you're proposing).