One of our developers is continually writing code and putting it into version control without testing it. The quality of our code is suffering as a result.
Besides getting rid of the developer, how can I solve this problem?
EDIT
I have talked to him about it number of times and even given him written warning
Tell the developer you would like to see a change in their practices within 2 weeks or you will begin your company's disciplinary procedure. Offer as much help and assistance as you can, but if you can't change this person, he's not right for your company.
Why not just talk to him? He probably won't actually bite you.
You know, this is a perfect opportunity to avoid singling him out (though I agree you need to talk with him) and implement a Test-first process in-house. If the rules aren't clear and the expectations are known to all, I've found that what you describe isn't all that uncommon. I find that doing the test-first development scheme works well for me and improves the code quality.
If you are at a place where you can affect the policies, make some changes. Do code reviews before check ins and make testing part of the development cycle.
If you have automated builds set up, then make sure that the failure notifications are both as obvious and annoying as possible. Wallboards or audio notifications in the development common areas are a good start. Then, make sure that one a build is broken, make sure that no one checks in code until the offender has fixed the problem.
Granted, this will only catch it when his code breaks the build, but the peer pressure for him to continually be spotlighted for this will be an incentive for most. In the event that this does not help, take the next discinplinary actions available through your human resources department. You have already talked to him, you already have given a written notice - find out what the next steps are. A developer who goes his own way is either a visionary or not a team player - and I have never personally had the pleasure of working with a visionary in that regard.
Code reviews and unit tests.
Having been (like many people) the guy who checks in a trivial change and breaks things, I can tell you that unit tests remove any excuse for not testing, if they are setup so you can run the whole panoply quickly, and they help identify who broke the code (assuming a decent VCS). Of course, with informal code reviews, I've checked in trivial code that has been reviewed by a senior (and competent) colleague, and still broken the codebase.
I would suggest (as others):