On our Scrum team there are a couple of members who crank stuff out to the page without unit testing, then complain when changes are made elsewhere in the code that break their stuff. The refrain is always "It used to work, what did you do?"
We are early in moving to Agile, and CI is one of the next things on the agenda. Until then, how do I deal with the people problem? That's the part that is hardest to deal with, after all.
You are the team so you have to agree before you get down to work. Without agreement blame game will go on forever (and it is true just about anything).
See my answer to the question about the value of unit testing: http://stackoverflow.com/questions/708047/the-value-of-unit-testing
I think the best way to deal with this kind of stuff is through accountability. If their stuff breaks, they take the heat and have to find the fix, even if the root cause is somewhere else, their portion of the problem is that they didn't catch it prior to release.
Note that this may not actually convince them to change their habits though...
Talk to them. Ask why they don't do unit tests. If it's just laziness, explain how it's a time-saver in the long run (with the specific examples you mentioned), and that yes, it takes some effort to get into, but soon becomes a habit with proven benefits.
If that doesn't help, give them a separate time buget for unit tests and implementation and tell them that it's now their job to spend 5 hours writing unit tests for this use case that produce decent coverage, and that you'll be happy to help them get started.
If that still does not help, fire them and get someone who won't disregard outright orders to do his job properly.
I'd start by looking at your team policies. Why are they allowed to submit code without unit tests in the first place? If you want consistent unit tests then you need to set the policy. You can explain that unit tests are an important way catch regression issues. If they continue to complain, point to the policy and tell them unit tests are not optional.
Use a continuous integration system with a good blame mechanism. Something like Hudson that can continuously check Subversion or other source control systems. Set up your CI build system to send an email as soon as a system test fails that broadcasts the name and change that introduced the error.
In other words, make sure that everyone knows who is introducing the bug and identify the bugs as soon as they are introduced. Over time, these cantankerous developers are going to realize that they are the ones introducing defects.
Playing devil's advocate here, but why are changes elsewhere breaking their code? Would unit tests actually prevent this breakage? Are people breaking or changing interfaces between code units?
I mean, yes, unit tests and design-by-contract are great things, but the code has to have a contract to adhere to. Getting these programmers to write unit tests will help determine when you have a problem, but does it get you closer to preventing those problems? It sounds like there may be a larger design issue that needs to be addressed.
I swear sometimes half of this site is thinly-vieled complaining about your job.
Download and install TeamCity by Jetbrains. It's Continuous Integration you can set up in an hour. Have your unit tests automatically run as part of the build. When they fail, everyone knows why and looks to the person whose changes made the build break.
Stop griping and use technology to solve your problem.
Whoever breaks the build without writing unit test needs to buy a luch for the whole team.