What automated build systems are you using? How long do your builds take

There are a number of optimization strategies you can do to improve the throughput of tests, but you need to ask yourself what the goal of this testing is, and why it needs to be fast.

Some tests take time. This is a fact of life. Integration tests usually take time, and you usually have to set up an environment in order to be able to do them. If you set up an environment, you will want to have an environment which is as close to the final production environment as possible.

You have two choices:

1. Optimize the tests, or the deployment of the tests.
2. Don't do them as often.

In my experience, it's better to have an integration environment which is correct, and finds bugs, and represents the final production environment adequately. I usually choose option 2 (1).

It's very tempting to say that we'll test everything all of the time, but in realilty you need a strategy.

(1) Except if there are loads of bugs which are only found in integration, in which case, forget everything I said :-)

Having Project A build is straight forward. In the publishing phase write a file to a network drive.

Project B can use the files system source control block to monitor the network file system, and trigger a build based on the change from Project A. When it is done it writes another file to the file system (different dir).

Project C is using the file system source control to watch for changes from Project B.

All pretty simple.

If you don't have a shared file system you can also use ftp, scp, or http to move trigger files around.

If you prefer you can trigger a build using the web interfaces, called from the Project A and Project B publishing phases.

Wrt the questions in the comments, you can get information on Project B failing (at least) two different ways.

One would be to have a Project B under CC that served as a proxy for the remote Project B. The remote Project B would write a file during the publishing phase and in the file indicate if it passed or failed. The proxy-B project would monitor that file and during its "build" phase would read the file and pass or fail based on the contents. Project C now just monitors proxy-B using CC's BuildStatus element.

Another way to approach the problem would be to replace Project B under CC.net with CC's DistributedBuilder which uses JavaSpaces to distribute builds to remote agents: http://confluence.public.thoughtworks.org/display/CC/Using+distrib+from+the+CruiseControl+contrib

In the distributed approach Project B would still be run on the windows machine but the DistributedBuilder would run the script remotely and then bring the results back to the CC server.