My co-worker not only doesn't create unit tests, he comment out my own unit tests after he changes the code and the test breaks.

Stab him in the back, literally or not.

You might wanna let your boss know...

Not if he stabs him...

Getting angry just thinking about this.

Are code quality metrics/tools part of your build process? I feel like the only way to train some people is to enforce that each version/release should have same or better code quality and test coverage...

Coworker deleting my code, thinking I broke the application. Later finds out it was broken by someone else's commit. Yeah, it happened. I was beyond pissed. :/

Print out the diff of the logic change and diff of commented unit test.

Hang them on the fridge side by side.

Deny knowing anything about them if he's even dumb enough to point out its his code and you made fun.

@deMark doesn't really work sadly if people don't learn to enjoy improving quality. I have seen lots of people go to extreme lengths to cheat the quality metric tools to stop flagging their changes.

@Henrik I was thinking about this the other day that people could write fake unit tests to cheat the metrics but that's almost as much effort as writing real ones...

@deMark sadly very easy to fake. If you are making a web api for example just write a test that calls one of the api methods then mock nothing in the test except the database, and no asserts in the test at all. And voila, free coverage without actually covering anything.
I have seen so many of those over my years, and very little to no interest from the people that made them to fix them.

Hey bossman, do you know why Frank is commenting out my unit test?

It's no effort at all to fake.

Assert.IsTrue(true)

This is why code reviews are important.