Unbreakable Functionality

Let's pretend (as in: "pretend", not as in: pretend) that you work with a coworker who is in such a hurry that he won't manually test his code before he checks it in. Let's also pretend (in the same sense) that you write decent UnitTests, but that this coworker never bothers to run them.

The surest way to “unbreakable” is, of course, to get the coworker out of his clinch. See: WhyDoYouPermitThisToBeDoneToYou and SlowDownToSpeedUp.

Given that environment, how can you write functionality so that it has better odds of surviving?

Be simple. If there's more than a couple conditional paths, odds are that the hacker's hasty testing won't catch them.
Be tight. Put dependent pieces of logic very close to each other so that the hacker is more likely to see them.
Be blatant. Subtle aspects of your code will get trounced.
Be watchful. Monitor all commit logs. Run the tests after every commit. Update the tests when he doesn't. Update the tests when he introduces a bug you didn't test against.
Be visible. Gently find a way to make the problem visible to the rest of the team and the management. Don't silently lower your velocity while you patch up the results of the hacker's corner-cutting. Could you provide more specific suggestions?
Automate. Set up a build machine that builds and tests continuously. Record whose code goes into each build. Create a Web interface to this record. See TinderBox or ContinuousIntegration.

Note: Most of these are good things, even if you've got a staff of the most careful programmers around.

I would add that automatically mailing people notifications of broken tests can help modify their habits. It's less confrontational than nagging people to their face, if instead they get a mail saying "you were the last person to update this file, and this file broke the build/this test failed". You can use CVS history for this (if you have CVS).

CategoryTesting