Establish an agreement within the team about what will be tested and how it should be tested, and when it should be tested (before check-in, before it pushes, before it gets merged to trunk).
Then, when a check-in doesn't meet the set of standards the team agreed code should meet, simply roll it back, and ask the developer to fix it. Rolling check-ins back are an incredibly effective way to both preserve the quality of the codebase in the face of poor quality check-ins, and as a lightweight way to signal to people that their code doesn't meet the standards set by the team.
The nice part about rollbacks is that it's really easy to check the code back in - just rollback the rollback, fix whatever the issue is, and then check the change again.
I would be careful to do it in a very objective way that doesn't signal anyone out. This means applying it to the whole team, not just your problem member, and focusing on making it more about the quality of the code and having the code that gets checked in meet the standards the team set with each other, rather than as a punishment.