We're working on a large product which has been in production for about 5 years. The codebase is.. erm.. working. Not really well but it is working. New features are thrown into production and tested with a small QA. Bugs are fixed, etc. But no one, except me, is writing unit-tests. No one uses the power of "tracking" down bugs by writing unit tests to ensure this special bug (test case) would never, ever occur again. 

I've talked to management. I've talked to developers. I've talked to everyone in the whole company. Everybody says: "Yep, we must write more unit-tests!" That was about a year ago. Since then I have forced introduction of pre-commit code review (Gerrit) and continuous integration (Jenkins). 

I held some meetings about unit-tests and I also showed the benefits of writing unit-tests. But no one seems to be interested. 

Q1: How do I motivate my fellow co-workers to write unit-tests?

Q2: How do I stay motivated to follow my personal code quality standards? (Sometimes it' s really frustrating!)  

PS:
Some frustrating facts (reached in 1 year): 


Total unit-tests: 1693
Total "example unit-tests": around 50
Done by me: 1521


Edit: Am I expecting too much? Its my first working place and I'm trying to do my best. 

Edit 2: Based upon all answers I've made a small checklist for myself. I've talked to two developer in private and we had a good and honest talk. 

One of them told me, like Telastyn said, that he is really uncomfortable with unit-tests. He said that he would like to be "more professional" but he needs a kickstart.   He also said that our unit-test meeting with all developers (around 9-11) was good, but it was too crowdy. Meh. Some critics for me, but I'll learn from that. (see answers below concering tdd kata meetings!)

The other one said that he is not interested in writing unit-tests. He thinks that his work is good enough for his salary. He don't want to put more effort in. I was quite speechless. Typical 9-5 "worker".

Next week I'm going to talk to the other developers. 

Thanks for your great answers (so far!) and your support. I really appreciate it! I'ved learned a lot, thank you very much!

I noticed that talking about TDD hardly works. People like to see raw results. Saying that "writing tests will reduce development time" is most likely true, but it might not be enough to get anybody convinced.

I was in similar position (well, not as bad as yours), and it kind of resolved itself when people started working on my code (note: my code was unit tested, others' not so much). When something stopped working, natural follow-up after local investigation was to ask me what could be the reason. Then we sat, we ran unit tests and saw what happened. If tests were passing, most of the time problems were in the new, untested code. If not, tests were usually able to spot the problem (or at least point us in the right direction). We fixed the bug, tests were up again, everybody was happy.

Long story short, a few situations like this transpired and 2 more developers became TDD/testing enthusiasts (there are still a few more to go, but it looks promising).

As for advice, you can give a go with TDD kata; simple task to implement using a test first approach as opposed to no tests. Depending on how complex the task is, non-test approach should usually be slower, especially with incremental required changes:


Roy's string calculator
Bank OCR


Edit: OP's comment made me realize there's even stronger argument at his disposal - regression aka returning bugs. Those kind of situations are perfect examples demonstrating how benefical unit tests can be. People like numbers - like I said, telling "unit testing is good" might not be convincing, but arranging data like below might surely be:


time spent to implement feature (no tests were written; I assume this happened often so it should be relatively easy to find such example)
estimated time to implement feature with TDD (or even tests after approach; doesn't matter - what's important is presence of unit tests)
time spent resolving the bug on untested vs tested code


One thing to warn you about (this migth be obvious but is worth noting): outcome bias - make sure you don't select example where the only way of spotting bug with test was to write test for that bug. Usually, nobody knows bug will occur upfront, but it's tempting to say "man this bug would be trivial if we had test for X" - it's easy to find a winning tactic for a war after it has ended.

Outcome of those examples should be simple question - if you could spent x-hours developing feature Y, why would insist on doing it in 2x?
