Disclaimer: I am approaching this as a programmer (who is here mostly to learn how to better interact with our testers.)
It's important to remember that the developer has not always been told how to test the code. Although we wish it wasn't true, the developer was given a set of requirements from someone who really didn't care about every aspect of the system. You can't expect every dev to know every part of the system.
So, the dev gets the spec, notes down the requirements (that were provided to him) and makes sure those requirements are met. Unfortunately, there are two or three other requirements not on the spec that were pre-existing, and now broken.
Whose fault is it? Is it the dev for breaking the existing requirements? Or was it the person who generated the spec and only told him what things to test? To be honest, in a lot of companies, developers aren't even told what they need to test.
Now, for me personally as a developer, if you tell me a way I can test a piece of code better, please do. If I can stop the bug from ever seeing you, I want to do it. Otherwise, I have to fix it in three days from now when the change filters its way up to you and then back down to me, I've forgotten everything about it, and it takes me an hour to make one simple fix that should've taken me 30 seconds when I ran that test.
So you can tell a dev they're not testing their code by giving them advice instead of orders. You can say "hey, I've noticed a few patches come up that have XYZ-attribute about them. Typically, I test them with __input and catch a lot of bugs that way." Most developers I know would love to avoid going back and fixing their code after it's gone out, and will be receptive to that.
I promise you if you're confrontational about it, you'll get a very angry developer who will throw a hissy fit. In that case, you'll be saying "You have buggy code" instead of saying "Hey, here's a way to be more efficient." The latter is much more appealing, and productive!