Tests problems


#1

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 |
`========================’


#2

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.


#3

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 :slight_smile:

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 |
`========================’


#4

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

:slight_smile: But it’s the same problem: loading the same data each time.


,========================.
| Pierre-Alexandre M. |
| email : removed_email_address@domain.invalid |
`========================’


#5

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!!


#6

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!!


#7

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 :slight_smile:

(My $0.02)


,========================.
| Pierre-Alexandre M. |
| email : removed_email_address@domain.invalid |
`========================’


#8

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 |
`========================’


#9

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!!


#10

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


#11

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…

:smiley:


,========================.
| Pierre-Alexandre M. |
| email : removed_email_address@domain.invalid |
`========================’


#12

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!!


#13

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 :slight_smile:

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


,========================.
| Pierre-Alexandre M. |
| email : removed_email_address@domain.invalid |
`========================’


#14

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 :wink:

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 :wink: 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 |
`========================’


#15

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


#16

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!!