Listener daemonized or foregrounded forks a loader loader should load, setsid, then exit all workers then have the same sid and gid with no parent pid worker pgid = 100 sid = 100 webkit_server worker pgid = 100 sid = 100 webkit_server
performance.txt printing informational messages single specjour command starts daemon interrupts handle no careful_test database bonjour announce project names printer#project_name aliases
# specjour listen
gem install specjour
Each worker needs an isolated database. Modify the test database name in your
config/database.yml to include the following environment variable (Influenced
test: database: project_name_test<%=ENV['TEST_ENV_NUMBER']%>
source .dev bin/specjour listen -f -l bin/specjour spec/
specjour to start a dispatcher, manager, and multiple workers in the same
$ cd myproject $ specjour
If you wish to share your computing power with the rest of the computers in your network, run
specjour listen to start a long running process. The next time you, or any of your co-workers run
specjour, they'll find your machine.
$ specjour listen
Dispatch the tests among the managers in the network. Specjour checks the 'spec' and 'features' directories for tests to send to the listening managers.
The first parameter of the specjour command is a test directory. It defalts to the current directory and searches for 'spec' and 'features' paths therein.
$ specjour spec # all rspec tests $ specjour spec/models # only model tests $ specjour features # all features
Specjour allows you to hook in to the test process on a per-machine and per-worker level through the before_fork and after_fork configuration blocks. If the default hooks don't work for your project, they can be overridden.
# .specjour/hooks.rb # Modify the way you use bundler Specjour::Configuration.before_fork = lambda do system('bundle install --without production') end # Modify your database setup Specjour::Configuration.after_fork = lambda do # custom database setup here end
A preparation hook is run when
specjour prepare is invoked. This hook allows
you to run arbitrary code on all of the listening workers. By default, it
recreates the database on all workers.
# .specjour/hooks.rb # Modify preparation Specjour::Configuration.prepare = lambda do # custom preparation code end
The standard rsync configuration file may be too broad for your project. If you find you're rsyncing gigs of extraneous data from your public directory, add an exclusion to your project's rsyncd.conf file.
$ vi workbeast/.specjour/rsyncd.conf
By default, a manager will listen to the project in the current directory. If you want to run tests for multiple projects, use the
$ specjour listen --projects bizconf workbeast # run tests for the bizconf and workbeast projects
By default, the dispatcher looks for managers matching the project's directory name. If you have multiple teams working on different branches of the same project you may want to isolate each specjour cluster. Give your project an alias and only listen for that alias.
~/bizconf $ specjour listen --projects bizconf_08 ~/bizconf $ specjour --alias bizconf_08 ~/bizconf $ specjour listen --projects bizconf_09 ~/bizconf $ specjour --alias bizconf_09
Commit the .specjour directory but ignore the performance file. The performance file constantly changes, there's no need to commit it. Specjour uses it in an attempt to optimize the run order; ensuring each machine gets at least one long-running test.
$ cat .gitignore /.specjour/performance
If you want to hack on specjour, here is how to test your changes:
source .dev rake # run the test suite sanely specjour # run the test suite with specjour
Then if all is good, go to another app and test your changes on your test suite:
gem build specjour.gemspec cd /path/to/your/project gem install -l /path/to/specjour/latest.gem specjour
$ source .devto ensure you're using the local specjour binary, not the rubygems version
Copyright (c) 2010 Sandro Turriate. See MIT_LICENSE for details.