You can also match several packages using simple globbing, eg: my.packages.*

The parameter 'zope2-instance' allows you to specify the name of the part
which corresponds to the zope instance roadrunner will work against. The
default is 'instance'.

By default resident Plone site will be created. This should work in most
situations where you are installing add-on products that use install methods
or GenericSetup profiles.

setup-plone=0 allows you to disable the Plone site setup optimization. You
might need to do this in certain situations where you are using the profile_id
parameter.

Then you can run roadrunner::

$ bin/roadrunner -s my.package

It will preload Zope & Plone, then fork off the first testrunner. Once the
first testrunner is complete you will receive the roadrunner prompt where
you launch additional tests.

Recipe Options
==============

zope2-instance:

The zope2 instance to use for basing the installation on. Defaults
to 'instance'.

Gotchas
=======

- roadrunner is still a bit experimental. If in doubt, check it with the
regular testrunner. If you find a difference please send some details
including traceback, product versions, buildout.cfg and your tests.

- It may require you to change your test setup slightly if you haven't yet
already.

You'll be fine as long as you follow the standard sequence of importing your
product, loading its ZCML and then calling ztc.installProduct within an
@onsetup deferred method.

This allows the loading of your product to occur in the child testrunner
process which critical that roadrunner does what its supposed to do.

- Because it preloads the Plone environment you won't be able to see changes
to the Core Plone components. However, it should see all changes in your
application code which is what you will most likely be changing anyways.

Other options to speed up Plone testing
=======================================

plone.reload is excellent to do exploratory testing and development.

Known Issues
============

- ZCML registrations lost. This can occur if you run unit tests which employ
PlacelessSetup. A simple workaround is to avoid running unit tests and
integration tests together with roadrunner. You can run them separately
without issue.

Source & Bug Tracker
====================

Source Code:

http://github.com/hexsprite/roadrunner

Tracker:

http://hexsprite.lighthouseapp.com/projects/21973-roadrunner

Tested With
===========

Plone 3.1.x Let me know if you get it working on anything else.

Have also had reports of success with Plone 2.5.x

Also there are reports of success with Zope 2.9.8 and Plone 2.5.5.

Windows is untested and probably does not work currently. Feedback and patches
accepted.

Author
======

Send questions, comments & bug reports to:

Jordan Baker <jbb@no_spam_plz_scryent.com>

License
=======

Licensed under ZPL 2.1
see doc/LICENSE.txt

Changelog
---------

0.2.3.1 (Jun 25, 2009)
======================

- Added a MANIFEST so this can be built by pythons without git support installed.

0.2.3 (Jun 16, 2009)
====================

- Bug #4: OSX Core errors due to no exec after fork.

- Bug #2: the roadrunner script was not being updated properly. now when you
re-run buildout it will pickup new dependencies.

0.2.2 (Jun 1, 2008)
===================

Bugs Fixed:

- zope2/lib/python was being placed at the very start of the path which didn't
allow newer eggs to be seen. Now placed at the end of sys.path.

New Features:

- hack to reset terminal after you kill PDB. May need work for Windows.

0.2.1 (May 26, 2008)
====================

- fixed bug in the buildout recipe that excluded Zope from the sys.path. Bug
crept in because of "dirty" python install. virtualenv --no-site-packages is
your friend.

- removed an annoying child process message.

0.2 (May 25, 2008)
==================

- added a zc.buildout recipe to setup roadrunner with Plone

- fixed globbing for packages under test

- fixed child signal handling so you can reliably interrupt running tests
without killing the parent