[rspec-users] spec_server requiring absolute paths (and autotest breaking)

Jarkko Laine jarkko at jlaine.net
Thu Feb 21 01:20:58 EST 2008


On 21.2.2008, at 4.14, Scott Taylor wrote:

>
> On Feb 20, 2008, at 1:52 AM, Jarkko Laine wrote:
>
>> On 20.2.2008, at 6.55, Scott Taylor wrote:
>>>> That said, now that autotest runs via drb, it's vastly (like 50%)
>>>> slower than without it,
>>>
>>> That's the idea.
>>
>> Isn't the idea that specs run faster through drb, rather than
>> slower? However, in general my specs seem to take a lot longer when
>> run through autotest in the first place (compared to running just
>> rake spec:models, e.g.). I haven't so far been able to track down
>> what causes this.
>
> Oops.  Misread your post.
>
> Is this true running a single spec (or a single file)?  I've noticed
> that a test suite which takes about 5 seconds normally takes about 7
> seconds under drb (according to the numbers reported by rspec).  Then
> again, running a single file is blazingly fast, as their is no wait
> (as though I'm testing against a non-rails project).

If I run a single, small file (like a helper spec), it's faster in an  
absolute sense (using time):

Probutanol:koulutusweb jarkko$ time script/spec -O spec/spec.opts spec/ 
helpers/date_extension_spec.rb
....

Finished in 2.061605 seconds

4 examples, 0 failures

real	0m2.212s
user	0m0.060s
sys	0m0.024s
Probutanol:koulutusweb jarkko$ time script/spec spec/helpers/ 
date_extension_spec.rb
....

Finished in 0.102506 seconds

4 examples, 0 failures

real	0m4.682s
user	0m3.738s
sys	0m0.688s


However, as you can see even there the actual running of the specs is  
painfully slow (2 vs 0.1 secs) and the only reason drb is faster is  
because there is no startup time. This is on 3316. Also, there really  
seems to be something wonky going on with the loading. When I run a  
model spec right after starting the spec server, it works, but running  
it the second time already gives some weird stuff back:

Probutanol:koulutusweb jarkko$ time script/spec -O spec/spec.opts spec/ 
models/account_spec.rb
..........

Finished in 0.371612 seconds

10 examples, 0 failures

real	0m1.647s
user	0m0.068s
sys	0m0.024s
Probutanol:koulutusweb jarkko$ time script/spec -O spec/spec.opts spec/ 
models/account_spec.rb
.FFF.FFFFF

1)
ActiveRecord::AssociationTypeMismatch in 'Account users should return  
user'
Address expected, got Address

>
>>
>>>> Mock 'Location_18994' expected :valid? with (any args) once, but
>>>> received it twice
>>>
>>> I saw this happen recently when the spec server was started twice:
>>> once with the rake task (rake spec:server:start), the other with a
>>> straight script/spec_sever.  My hunch is that both servers are
>>> loading the files at the same time.
>>
>> That would seem logical. However, I just checked that I only have
>> one spec_server process running and am still able to reproduce the
>> problem.
>
> Hmm.  Are you reloading classes or using anonymous classes derived
> from AR::Base, or anything crazy like that?  Are all your models in
> app/models?  Do you have pending migrations?  Are your running with
> rake, or with autotest? How about running the file alone?

Doesn't matter. Shouldn't be doing anything super special with models  
but got to think about it.

>>>> expected: "Barney Hops doesn't have the required competency (MBA)
>>>> to teach this class",
>>>>    got: ["Barney Hops doesn't have the required competency (MBA)
>>>> to teach this class", "Barney Hops doesn't have the required
>>>> competency (MBA) to teach this class"]
>>>>
>>>
>>> Yeah - this is because rails load's instead of requires.  You'll  
>>> also
>>> see this sort of thing if you just call load directly in your specs.
>>> I've never dug deeper into how all of the rails magic happens
>>> regarding loading and constants (and the method generation with the
>>> association macros (has_* belongs_to), so if you have any insight,
>>> I'd be happy to hear it.
>>
>> Yeah, all these failures are certainly related and probably caused
>> by something like what you describe. Got to try to figure out what
>> spec_server does differently than normal spec. Or maybe we should
>> just bite the bullet and make the deeptest spec fork work :-)
>>
> Yeah - deeptest is great for slow suites, but now that I have a fast
> suite (take 5-7 seconds), deeptest probably wouldn't be much of a
> performance gain for me.

Yeah, the funny thing is, model specs that sometimes need to go to the  
db are pretty fast but controller specs where most of the db traffic  
is stubbed out seem to become a drag, and I would think deeptest would  
help there.

--
Jarkko Laine
http://jlaine.net
http://dotherightthing.com
http://www.railsecommerce.com
http://odesign.fi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2417 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rspec-users/attachments/20080221/5338a226/attachment.bin 


More information about the rspec-users mailing list