There are other ways to test legacy code rather the applying unit testing. If no testing is present at all, unit testing is not likely the correct approach and function/integration testing (using a PhantomJS for example) might be more suitable.

None of the options being discussed are "simple". There isn't a simple way out of technical debt. If there were, it wouldn't be debt.

Unit tests rarely contribute much to the technical debt, because worst generally-seen case is that you can just throw them away. I've seen that, unit tests so bad they weren't usable for much. I'm yet to see a code base destroyed by trying to make it testable, whereas I've seen a ton of codebases that were made quite powerful and flexible, yet also fairly pleasant to use, because they were built to be testable.

Also, in the end I'm far more interested in "automated" testing than anybody's pedantic definitions of what "unit" or "integration" or whatever testing is. That's not the point. The point is that I ought to be able to set up an automated built server and run useful, meaningful tests on it.

I once encountered old code where many of the functions had an argument "bool isUnitTest". Counting the number of things that have to be wrong with the workplace in order for this to occur and to be acceptable is left as an exercise for the reader.

Worst codebase I have ever seen. The incumbents had zero interest in paying down technical debt. Unit tests were just another thing that could be used to game metrics and justify budgets.

Metaphorically speaking, the group issued predatory high-interest payday loans to keep the customer paying increasing amounts of interest on a growing amount of technical debt, forever.