What is SpecServer?

Testing RSpec
1

I have looked through the docs, looked at the code, even gave a
cursory (2 page) glance at google, and it is not clear to me what
SpecServer is or what it is for.

Is it meant to speed up the execution of specs in a rails environment
by doing some magic on the database?

Or I am thinking it keeps a copy of Rails running to avoid the rails
reload delay…

Is there any documentation on this so I can go find out instead of
bugging the list? :slight_smile:

Regards

Mikel

2

I guess I could just try it, but does spec_server work with autotest
too?

ie.
ruby script/spec_server &
autotest

?

On Wed, Mar 12, 2008 at 9:36 PM, Scott T.

3

On Mar 13, 2008, at 12:17 AM, Mikel L. wrote:

I have looked through the docs, looked at the code, even gave a
cursory (2 page) glance at google, and it is not clear to me what
SpecServer is or what it is for.

Is it meant to speed up the execution of specs in a rails environment
by doing some magic on the database?

The spec server does no magic. It load the rails environment, and the
runs the specs through Drb (look up the rdoc for Drb/Rinda).

Or I am thinking it keeps a copy of Rails running to avoid the rails
reload delay…

Yep - that’s pretty much it. It usually takes a few seconds to load
up the rails environment, and if you are running your specs every few
seconds, that can shave off a lot of time from your dev cycle over time.

Is there any documentation on this so I can go find out instead of
bugging the list? :slight_smile:

No - not really. All you need to do is start the spec_server:

ruby script/spec_server

The specs can then be run through the server with --drb (put it in
spec.opts, if you always want to use it).

Scott

4

On Mar 28, 2008, at 2:35 PM, David B. wrote:

I guess I could just try it, but does spec_server work with
autotest too?

ie.
ruby script/spec_server &
autotest

Sure.

Autotest is a pretty stupid program (and I mean that in a good way).
All it does is periodically run a spec command in a subshell.

Scott

5

On Mar 29, 2008, at 11:11 PM, David B. wrote:

when you need to. If you make changes to your application that are
For which of those cases do you have to restart spec_server and which
script/spec command the specs are sent to the spec_server which
already has your Rails environment fired up and ready to go. If you
happen to install a new plugin or something like that, then you’ll
have to restart the spec_server.

No - It should work - Remember: Autotest is DUMB. Dumb, dumb, dumb.
It’s a great tool, but it was written before rspec. It has nothing to
do with rspec. All it does is watch a series of files, and reruns a
certain command when one of those files changes.

So - Autotest has no knowledge of the internals of Rspec. The BUG was
that if you put the --drb (or the equivalent -X) flag in your
spec.opts file, Rspec would not run them with the drb server. This
bug has been fixed in trunk (as far as I know).

Scott

6

Just to help clarify for the newbies like me. script/spec_server runs
in conjunction with script/spec but not ruby your_spec.rb. It seems
like the way to use script/spec_server is to have 2 console programs
open:

ruby script/spec_server

That will have the spec_server running in the background and your
entire application loaded into memory at the time of execution, and
since it’s on top of once console it will be easy to kill and restart
when you need to. If you make changes to your application that are
loaded up only in the beginning (like installing a new plugin), then
you’ll have to restart spec_server. (Q: What about the following
cases:
make a database schema change,
add another user-defined model,
add another controller,
edit an existing controller,
edit an existing model
make changes to your routes.rb file,
edit a plugin.
For which of those cases do you have to restart spec_server and which
cases don’t you? )

And in another console run the spec you’re working on:

ruby script/spec spec/models/your_spec.rb --drb -c

I’ve noticed that autotest doesn’t send commands to the spec_server.
Instead it reloads the entire Rails environment and your application’s
plugins everytime it executes. This causes autotest to run
significantly slower than script server, because when you run the
script/spec command the specs are sent to the spec_server which
already has your Rails environment fired up and ready to go. If you
happen to install a new plugin or something like that, then you’ll
have to restart the spec_server.

Feel free to correct me, if I’m wrong. I’m just trying to shed some
light for new users, hopefully without saying anything that’s not
right. I’m just learning all this stuff.

David :slight_smile:

On Mar 28, 9:17 pm, Scott T. [email protected]

7

On Mar 29, 2008, at 11:11 PM, David B. wrote:

when you need to. If you make changes to your application that are
For which of those cases do you have to restart spec_server and which
cases don’t you? )

I’m replying in chunks here, but:

AFAIK, anything which is required will need to be reloaded (if it
changes). Also - any change to rails itself.

Schema changes will require you to reload the server. Not sure about
a new model, but, if you say, added a new column to a table, you would
most certainly need to reload the spec_server (as rails actually
caches ActiveRecord::Base.columns, much to my chagrin the other day in
a migration).

Anything which is loaded with Kernel#load (or load_once, or whatever
rails does) shouldn’t cause you to reload the spec server. So - this
means changes to the code of a model or a controller should be safe,
since they are load’ed, not required (as require does nothing but
return false the second time it is called).

I’m not sure about the routes or the plugin scenario. I would assume
for the plugin that it depends on how the code is internally loaded
up. If it is require’d instead of load’ed, I’d bet that you need to
change the spec_server.

Also - just a tip for those who might be using (or thinking of using)
the spec_server: I’ve noticed that shared example groups aren’t being
reloaded properly. This is a bug in rspec which I’ve yet to file a
ticket for, mainly out of lack of time. Next time I run across it,
I’ll report it.

Scott