Nobody gets paid proportionally to the number of unit tests they produce. That’s a good thing.
But how, then, do we motivate the many developers who think that they should do unit tests and/or TDD but don’t? It’s not easy to do serious unit testing and TDD when there’s legacy code (i.e. code without unit tests), and it’s never the most important or urgent thing.
The short answer is “culture”. The whole team should understand that you write unit tests and do TDD because it’s what a professional developer does. A professional surgeon washes hands before surgery. A professional chef makes sure the kitchen is clean at closing time. You get the idea.
It also helps to have a software factory set up where the coverage rate is tracked. Requiring a specific coverage rate is a questionable practice because 100% is sometimes too much (for example, if you need to implement a 3rd-party interface with 50 methods just so you can use one of them, do you have to write bogus unit tests for the 49 empty method implementations which are required by the compiler?), and less than 100% can lead to developers avoiding testing the most difficult-to-test but most important code. However, it’s motivating to see the effect that one’s commit has on the coverage number, be it the overall coverage or the coverage for the specific classes or packages which were modified.