Having production code with good test coverage is very beneficial to a development team.
Broad coverage can catch bugs and unintended behavior from...
For further actions, you may consider blocking this person and/or reporting abuse
Is it really possible to cover untested code?
And to cover years of code that is untested which also means it was not designed to be testable and therefore is tough to test?
From my experience, in the end we cover new features (that do not rely on too much old code) and easy to test code (helper classes or very small modules).
Covering the whole thing takes tremendous time not only of test writing but also massive refactoring to get it to be testable. Problem is, we do not have tests to cover our asses while refactoring so the risk is really high.
Of course keeping untested old code is risky too...
At the end of the day, I believe that being in the situation of a big codebase with very little testing is awful with very little hope of improvement (does not mean we should not try)...
I'd go with the Scouts mentality of leaving code better than you found it. Add tests when you're touching a piece of code, so you can already edit it to be more testable. Yes that might be a slightly risky refactor because it's not covered by tests, but then again, it's no more risky than the development you did before TDD.
+1 for starting with test coverage for new features
For legacy code, one option might be partial/incremental refactoring of code and apply test coverage for "low hanging code fruit" e.g. legacy features easy to recode/restructure
I'm a strong believer in unit tests. I heard a while back when I first started programming that if it's hard to write a test for something then you should probably look at rewriting that section of code. Obviously this doesn't apply as much to old code as it does new features depending on the application (if it isn't broke don't fix it). This "rule" does make me look at the code I write with more scrutiny and it helps me to write more maintainable code. Another added bonus of unit tests is knowing that what you wrote doesn't introduce any unexpected problems (if you write something and unit tests that were previously passing are now failing then it allows you to catch the problem before pushing).