Back when I was working as team lead/development manager, the rule was that you wrote tests as you went along and kept them with the Source Tree in the ../t sub-directory of the component you were working on. That allowed the developer the most freedom to pick and choose the tests that they needed to run during the day.

At 2300 the source tree was swept for changes and the Product Build kicked off. If the Build was successful, then all the /t directories were swept and executed. (The test-sweep was a separate Build, so we could schedule it apart from a Product Build.) When I showed up at 0800 the following morning, I had most of the data I needed for the 0830 Coffee and Scrum, before we split up for the day. ("OK, People. Let's go and invent the Future!")

Since the Build took two to three hours and the Test Run took about the same, I had some slop in the nightly schedule. There was always some chat about trying to speed up the Build/Test, but so long as I had the slop time, I could successfully argue that that any 'tuning' represented false-optimization and besides, the nightly full test run was 'regression'.

The developers were at liberty to maintain their own order-of-march for the tests. Some just kicked off the entire suite for their component when they felt the need to (or wanted to get up and get more coffee). Others just limited themselves to the one or two tests that exercised their code change and let the nightly full test run check for cross-talk and regression in other parts of the Source Tree.

I guess I am saying that you need both kinds of test harnesses -- one that fails quickly for when you are head down in the Code, and one for regression that is very hard to kill. (Maybe call them 'Agile' and 'Timex'?)