The obvious benefit of unit testing is that we get an instantaneous overview of whether some basic, expected functionality of our web applications has been broken by recent changes. Depending on your project, and overhead involved, you may want to run unit tests on each save, each commit, each hour, day, or as part of your continuous integration process via Jenkins or TravisCI. You can use your unit tests to verify functional outputs, DOM manipulations, event-driven behavior, or even basic markup structure.
In the case of a monstrous amount of preexisting code, there’s not much that can be done as far as unit test coverage is concerned, except to say that this is the line in the sand. From here on out, all new feature work will require unit test coverage, and any new defects that are reported will require a unit test to verify their solution. In this way, you can let your test library organically grow, while still being able to handle feature work at the same time. Nobody needs to slam on the brakes to be able to write coverage for everything, especially when a lot of it may be dead execution paths, or code that’s slated for refactoring work in the future.