Social pressure in distributed teams

Unit tests aren't much good if you don't run them. Duh. Unit tests get in the way if they take a long time to run. Developers will avoid running them, even when social pressure is applied.

On my current project, we've tried to achieve a balance. The standard "build" that happens after normal editing runs the in-memory subset of our unit tests. (On a fast laptop, it adds less than 7 seconds to the build.) And I've arranged to fail the build if any test fails. Nobody complains, and large parts of our application stay unbroken.

The "live data" tests run separately, since they required creating a test schema and populating it with test data (and this requires access to a server, which isn't guaranteed for various semi-legimate reasons). This separation of tests works fairly well except that I can't get people to run the damn database tests on a regular basis. Waiting for the overnight build to catch problems takes too long; problems can multiply unseen in the interim.

There are technical aspects of this problem (e.g., we could, for a small expenditure of time, set up a continuous integration and test environment), but I think the bigger problem here is social.

Social pressure works well in colocated projects. One need only walk a few steps before applying a bitchslap. And "Whoever checks in broken code has to wear the funny hat to the morning meeting" can be very effective. I'm looking for techniques for applying pressure in a distributed team.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

Until recently I worked on a large distributed development project, for about 10 years, composed of different government labs and a large corporation. It is very hard to influence someone to do something right if they work for a different organization and they view you as not quite human since the only interaction they have with you is email or phone. (Hopefully this isn't the case.)

More than once I've seen folks sign off on tests, but there was no way they could have run the tests since by observation

On my current project we have an automated background process running the full test suite every couple of hours. If the tests pass, the code is tagged and checked out onto the staging server which is the first time the client gets to see/play with it. If anyone breaks the build, then no code gets promoted to staging. There's always at least one of us with some new code we want in front of the client so if the stick needs to be waved, we take it in turns to wave it.