Answers to your questions
Is there such a thing as having too many unit tests?
Sure... You could, for example, have multiple tests which seem to be different at first glance but really test the same thing (logically depend on the same lines of "interesting" application code under test).
Or you could test internals of your code that never surface outwards (i.e., are not part of any kind of interface contract), where one could argue about whether that makes sense, at all. For example the exact wording of internal log messages or whatever.
I have been tasked with writing unit tests for an existing application. After finishing my first file, I have 717 lines of test code for 419 lines of original code.
That strikes me as quite normal. Your tests spend a lot of lines-of-code on setup and teardown on top of the actual tests. The ratio may improve, or may not. I myself am quite test heavy, and often invest more l-o-c and time on the tests than the actual code.
Is this ratio going to become unmanageable as we increase our code coverage?
The ratio does not factor in so much. There are other qualities of tests that tend to make them unmanageable. If you regularly have to refactor a whole bunch of tests when doing rather simple changes in your code, you should take a good look at the reasons. And those are not how many lines you have, but how you approach the coding of the tests.
My understanding of unit testing was to test each method in the class to ensure that every method worked as expected.
That is correct for "unit" tests in the strict sense. Here, "unit" being something like a method or a class. The point of "unit" testing is to only test one specific unit of code, not the whole system. Ideally you would remove the whole rest of the system (using doubles or whatnot).
However, in the pull request my tech lead noted that I should focus on higher level testing.
Then you fell into the trap of assuming people actually meant unit tests when they said unit tests. I have met many programmers who say "unit test" but mean something quite different.
He suggested testing 4-5 use cases that are most commonly used with the class in question, rather than exhaustively testing each function.
Sure, just concentrating on the top 80% of important code reduces load as well... I appreciate that you think highly of your boss, but this does not strike me as the optimum choice.
To me, 100% unit test coverage is a lofty goal, but even if we only reached 50%, we would know that 100% of that 50% was covered.
I do not know what "unit test coverage" is. I assume you mean "code coverage", i.e. that after running the test suite, every line of code (=100%) has been executed at least once.
This is a nice ballpark metric, but by far not the best standard one could shoot for. Just executing code lines is not the whole picture; this does not account for different paths through complicated, nested branches, for example. It is more of a metric that points its finger at pieces of code that are tested too little (obviously, if a class as 10% or 5% code coverage, then something is wrong); on the other hand a 100% coverage won't tell you whether you have tested enough or if you have tested correctly.
It annoys me substantially when people are constantly talking about unit testing today, by default. In my opinion (and experience), unit testing is great for libraries/APIs; in more business oriented areas (where we talk about uses cases like in the question at hand), they are not necessarily the best option.
For general application code and in the average business (where earning money, hitting deadlines and fulfilling customer satisfaction is important, and you mainly want to avoid bugs that are either directly in the user's face, or which could lead to real disasters - we are not talking NASA rocket launches here), integration or feature tests are much more useful.
Those go hand in hand with Behaviour Driven Development or Feature Driven Development; those do not work with (strict) unit tests, by definition.
To keep it short(ish), an integration/feature test exercises the whole application stack. In a web-based application, it would act like a browser clicking through the application (and no, obviously it does not have to be that simplistic, there are very powerful frameworks out there to do that - check out http://cucumber.io for an example).
Oh, to answer your last questions: you get your whole team to have a high test coverage by making sure that a new feature is only programmed after its feature test has been implemented and failed. And yes, that means every feature. This guarantees you a 100% (positive) feature coverage. It by definition guarantees that a feature of your application will never "go away". It does not guarantee a 100% code coverage (for example, unless you actively program negative features, you will not be exercising your error handling / exception handling).
It does not guarantee you a bug-free application; of course you will want to write feature tests for obvious or very dangerous buggy situations, wrong user input, hacking (for example, surrounding session management, security and such) etc.; but even only programming the positive tests has a tremendous benefit and is quite feasible with modern, powerful frameworks.
Feature/integration tests obviously have their own can of worms (e.g., performance; redundant testing of 3rd party frameworks; since you usually do not use doubles they also tend to be harder to write, in my experience...), but I'd take a 100% positive-feature-tested application over a 100% code-coverage-unit-tested application (not library!) any day.