Forum: Ruby on Rails Tests problems

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Pierre-Alexandre M. (Guest)
on 2007-03-04 22:25
(Received via mailing list)
Hi,

I use fixtures to upload entries in my db. Actually, I have some
fixed informations I need to use in my application, so I have done a
migration_file for this. To upload it in my test_db, I use a script to
copy entries from my development database into yml fixtures files and I
run rake db:fixtures:load. Is this the right way to do a 'rake
db:migrate' in test environment ?

But, anyway, I've got some errors: the rake abords
I have some 'BIGBOSS = Person.find_by_name('admin').name' in my AR
models.
Running 'rake --trace' shows me that he doesn't find the entry 'admin'.
But the db:fixtures:load works because the entry 'admin' exists in my
table.
(Ok I can write a 'BIGBOSS = Person.find_by_name('admin')', not to have
the error when the model is loading but it will occure later)

Finally, when you run '--trace', a 'rake db:schema:import' is shown.
Does it creates a 'schema.rb' for tests? Actually, where does it find
the schema since at first time the test db is empty and you don't have
any 'rake db:migrate:test'?

What's wrong we me and the understanding of unit:tests?

Thanks,

--
,========================.
| Pierre-Alexandre M. |
| email : removed_email_address@domain.invalid |
`========================'
Bala P. (Guest)
on 2007-03-05 05:48
(Received via mailing list)
The way fixtures work is that you edit the yml file and define the
fields
and data. When you run the tests, the test will automatically populate
the
TEST database with the data found in your fixtures.

If you are using transactional fixtures, it will load the data at the
beginning of each test, run the test and rollback at the end of each
test.
This increases the speed of the tests. Of course you must have the
fixtures
declaration for the models that you want data to be loaded.

Follow the simplest way of doing this first and then you can move on to
complicated things with customized scripts.
Pierre-Alexandre M. (Guest)
on 2007-03-05 09:54
(Received via mailing list)
On Sun, Mar 04, 2007 at 10:48:06PM -0500, Bala P. wrote :
> Follow the simplest way of doing this first and then you can move on to
> complicated things with customized scripts.

The script isn't complicated at all :)

Anyway, my question was: how can I tell 'rake test:units' not to run
 'Execute db:test:purge'?
Or (that's equivalent), how can I tell him to execute
'Execute my_rake_file' just before he runs 'Execute test:units'?

Do I have to patch the rake file for unit tests? o_O

--
,========================.
| Pierre-Alexandre M. |
| email : removed_email_address@domain.invalid |
`========================'
Phlip (Guest)
on 2007-03-05 18:04
(Received via mailing list)
Pierre-Alexandre M. wrote:

> Anyway, my question was: how can I tell 'rake test:units' not to run
>  'Execute db:test:purge'?

I'm jumping in late, and I didn't read the thread, and I don't know
how to re-wire rake test:units, so...

...don't mess with Test Isolation. Your def setup(), and your
fixtures, should set whatever each test case needs up.

> Or (that's equivalent), how can I tell him to execute
> 'Execute my_rake_file' just before he runs 'Execute test:units'?

Amazingly bad style that might work:

  def setup()
    `rake my_rake_file`
  end

--
  Phlip
  http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!
Pierre-Alexandre M. (Guest)
on 2007-03-05 21:40
(Received via mailing list)
On Mon, Mar 05, 2007 at 08:02:54AM -0800, Phlip wrote :
> ...don't mess with Test Isolation. Your def setup(), and your
> fixtures, should set whatever each test case needs up.

Sure, but since there are fixed data that my app needs in my db, I
find stupid to load it with setup() each time it runs a test... A rake
db:migrate RAILS_ENV='test' would be much more useful but the 'Execute
rake db:test:purge' is runned whenever your rake tests. Hence my
question.

Anyway, I'm using a fixture file but I don't know if it's
really optimized... (sorry Mike if you read me, I'm focalised on
optimization :)).

> Amazingly bad style that might work:
>
>   def setup()
>     `rake my_rake_file`
>   end
>

:) But it's the same problem: loading the same data each time.

--
,========================.
| Pierre-Alexandre M. |
| email : removed_email_address@domain.invalid |
`========================'
Phlip (Guest)
on 2007-03-05 22:45
(Received via mailing list)
Pierre-Alexandre M. wrote:

> Sure, but since there are fixed data that my app needs in my db, I
> find stupid to load it with setup() each time it runs a test...

Stupid in what way?

Are you mentally comparing your setup to production code, which
generally should _not_ rebuild its database every few milliseconds?

Is this just some Académie-style hangup?

> Anyway, I'm using a fixture file but I don't know if it's
> really optimized... (sorry Mike if you read me, I'm focalised on
> optimization :)).

It's optimized for tests, right?

--
  Phlip
  http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!
Simon P. (Guest)
on 2007-03-05 23:55
(Received via mailing list)
Pierre-Alexandre M. wrote:
> Anyway, my question was: how can I tell 'rake test:units' not to run
>  'Execute db:test:purge'?
> Or (that's equivalent), how can I tell him to execute
> 'Execute my_rake_file' just before he runs 'Execute test:units'?
>
> Do I have to patch the rake file for unit tests? o_O
>
>
You can monkey-patched Rake but I'm note sure it is the nicest way to
do. Put this into a file under lib/tasks and you should be fine:

module Rake
  class Task
    def remove_prerequisite(task_name)
      name = task_name.to_s
      @prerequisites.delete(name)
    end
  end
end

Rake::Task['test:units'].remove_prerequisite('db:test:prepare')



Simon
Pierre-Alexandre M. (Guest)
on 2007-03-06 00:04
(Received via mailing list)
On Mon, Mar 05, 2007 at 12:44:47PM -0800, Phlip wrote :
> Stupid in what way?
>
> Are you mentally comparing your setup to production code, which
> generally should _not_ rebuild its database every few milliseconds?

Sure, it's one-shot but I have already 2000 tests. 'rake test' is
running in 25 sec. I just wanted to decrease this time, for the comfort
of developers.

> Is this just some Académie-style hangup?

?!

> It's optimized for tests, right?

Yes for tests. Why don't optimize test code? If you take care of your
test code just like you do with your production code, I'm pretty sure
the final application will be a strong one :)

(My $0.02)

--
,========================.
| Pierre-Alexandre M. |
| email : removed_email_address@domain.invalid |
`========================'
Pierre-Alexandre M. (Guest)
on 2007-03-06 00:11
(Received via mailing list)
On Mon, Mar 05, 2007 at 10:53:45PM +0100, Simon P. wrote :
> You can monkey-patched Rake but I'm note sure it is the nicest way to
> do. Put this into a file under lib/tasks and you should be fine:
>
> ../..

That's exactly the snippet I was looking for! Thanks a lot Simon.

--
,========================.
| Pierre-Alexandre M. |
| email : removed_email_address@domain.invalid |
`========================'
Phlip (Guest)
on 2007-03-06 00:22
(Received via mailing list)
Pierre-Alexandre M. wrote:

> Sure, it's one-shot but I have already 2000 tests. 'rake test' is
> running in 25 sec. I just wanted to decrease this time, for the comfort
> of developers.

Serves me right for not reading the thread. Switch the test database to
sqlite3.

May I ask if developers use 'rake test:recent' while writing features?
The total 'rake test' should only be needed at integration time...

> > Is this just some Académie-style hangup?
>
> ?!

I seek a word for the Gallic mindset that officialness makes things
right...

--
  Phlip
  http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!
Pierre-Alexandre M. (Guest)
on 2007-03-06 00:33
(Received via mailing list)
On Mon, Mar 05, 2007 at 02:20:10PM -0800, Phlip wrote :
> May I ask if developers use 'rake test:recent' while writing features?

I prefer rerun all the functionals tests when I change the code.

I should give autotest a try too why seems to optimize testing... I
assume it's based on the 'rake test:recent'.

> The total 'rake test' should only be needed at integration time...

Sure, but in my case, my unit tests are not long at all.

> I seek a word for the Gallic mindset that officialness makes things right...

:D

--
,========================.
| Pierre-Alexandre M. |
| email : removed_email_address@domain.invalid |
`========================'
Phlip (Guest)
on 2007-03-06 00:41
(Received via mailing list)
Pierre-Alexandre M. wrote:

> > May I ask if developers use 'rake test:recent' while writing features?
>
> I prefer rerun all the functionals tests when I change the code.

We ... might be talking past each other here.

rake test:recent runs every test file touched within the last 10
minutes. This includes tests in the unit and functional sub-folders.
So if developers can run that after every few edits, and if it takes <
10 seconds, you don't need to optimize anything.

Another trick (besides sqlite3 which you didn't respond to): Turn on
transactions, in the test_helper.rb file. Transactions that roll-back
after each test are always much, much faster than SQL operations that
commit all the way to the hard drive.

--
  Phlip
  http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!
Pierre-Alexandre M. (Guest)
on 2007-03-06 00:52
(Received via mailing list)
On Mon, Mar 05, 2007 at 02:40:55PM -0800, Phlip wrote :
> rake test:recent runs every test file touched within the last 10
> minutes. This includes tests in the unit and functional sub-folders.
> So if developers can run that after every few edits, and if it takes <
> 10 seconds, you don't need to optimize anything.

Oh, you're right. I was confused about this method. Thanks for the
explanation!

> Another trick (besides sqlite3 which you didn't respond to): Turn on
> transactions, in the test_helper.rb file. Transactions that roll-back
> after each test are always much, much faster than SQL operations that
> commit all the way to the hard drive.

Yes, Bala was right (Mike talk about it in the Agile Book). Sorry for
not replying :)

About sqlite3, you must be right too. Actually, I will give it a try
too.

--
,========================.
| Pierre-Alexandre M. |
| email : removed_email_address@domain.invalid |
`========================'
Phlip (Guest)
on 2007-03-06 01:02
(Received via mailing list)
Pierre-Alexandre M. wrote:

> About sqlite3

Three traps:

sqlite3 cannot nest transactions. So if something throws an error, the
rescue calls might hit 'rollback', and these might throw another
error, masking the first. To see the real error, temporarily turn off
transactions in test_helper.rb.

Next, sqlite3 cannot cohabitate with backgroundrb, because it's not
really a database; just a library that works off a single,
process-specific file handle.

Next, you might also try to get :memory: working, but I can't imagine
how that could be faster than transactions.

Next: Go to bed! Do you have any idea what time it is here???

--
  Phlip
  http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!
Pierre-Alexandre M. (Guest)
on 2007-03-06 01:10
(Received via mailing list)
On Mon, Mar 05, 2007 at 03:01:14PM -0800, Phlip wrote :
> > About sqlite3

Thanks for your tips. I'm gonna try and post a feed-back ;)

> Next: Go to bed! Do you have any idea what time it is here???

I guess, Mon, 5 Mar 2007 15:01:14 -0800 ?

Already to bed?! It's only 3pm ;) By the way, I have a lot of code to
write!

(And may be work for my exam on Wed...)

--
,========================.
| Pierre-Alexandre M. |
| email : removed_email_address@domain.invalid |
`========================'
Scott (Guest)
on 2007-04-27 21:53
(Received via mailing list)
Just wanted to say thanks... I was running into a similar problem to
others and this snippet of code did exactly what I wanted.

Cheers,

Scott
This topic is locked and can not be replied to.