Furthermore I can't find any guidelines for that, firm-wise.
That seems like the best place to start. Instead of treating this as an issue with one specific colleague and the way he does his work, approach it as an organizational issue (or at least, as a team-wide issue). Because that's what it is.
If the only things your colleague is omitting are things that do not impact upon the observable behavior of the code, then you really don't have a leg to stand on when you say things aren't done if there's no company-/team-wide policy that says "development work is not done unless...".
So I'd suggest you broach this topic to a project manager/team lead and approach it as a general process and quality improvement rather than a gripe about one person's behavior. Propose a definition of "done" that covers what you feel are the important points, and see if you can get buy-in (from other developers and management as well). Some things to include might be:
- Development work is not done unless the project compiles/builds successfully.
- Development work is not done unless all code has been peer-reviewed.
- Development work is not done unless every new line of code is covered by a unit-test.
- Development work is not done unless all new functionality is covered by integration tests.
- Development work is not done if there are any failing tests.
- Development work is not done unless all style guidelines and development best-practices have been adhered to.
- Development work is not done if the code still smells.
If you can't get buy-in for your definition of "done" then you may have to look at whether the organization is the right place for you, from a cultural perspective. Perhaps the only "done" the firm cares about is of the "observable functionality" variety, in which case your colleague is technically correct in calling his work done.
Which isn't to say that I think it's okay for an organization to not make code quality a top priority. But the fact of the matter is many of them do not.
In any case, if you approach it as an organizational/team issue, you remove any direct friction between yourself and your colleague. If the whole development team gets behind a consistent standard of "done" that includes the things you're most concerned about then your colleague has no reason to feel put upon or singled out by the requirements. Everyone is held to the same standards.