Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

dws (341)

  (email not shown publicly)

Journal of dws (341)

Friday February 20, 2004
11:59 AM

Social pressure in distributed teams

[ #17524 ]
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.
More | Login | Reply
Loading... please wait.
  • Create a little application that places a picture of the person that broke the build with the goofy hat on everyones desktop background. -- John C
  • 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

  • So what's the manual procedure to run the tests? Is it a single command/click?

    Does it block the development? (can it be run in the background?)

    Can it be run on both what's checked in and what's yet to be checked in?
    • The procedure for compiling the system, running the in-memory unit tests, and building a .war file for deployment is


      To do the same, and install in a Tomcat server, the command is

        ant install

      To compile the system, run the in-memory tests, then run the databases tests, typing

        ant dbtest

      does the trick, assuming that you have access to a live database server. Each developer gets their own sandbox, so there's no risk of A stepping on B.

      All of this is incredibly simple, but people wh

  • 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.