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 S. 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:
Heinz S. 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 S. 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).
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.