Yes, there is such a thing as too many unit tests.

While testing is good every unit test is a potential maintenance burden that is tightly coupled to the API, time that could be spent on something else, a slice of time in the Unit Test suite and may be adding no value because it is in effect a duplicate of some other test having miniscule chance that some other test will pass and this will fail.

It's wise to try and make sure you hit 100% coverage but that far from means a suite of tests each of which independently provides 100% coverage on some specified entry point (function/method/call etc.).

Pragmatics for most code indicates: 

 1. Make sure you have 100% coverage of entry-points and aim to be close to 100% coverage of 'non-errors' paths.

 2. Test any relevant min/max values or sizes

 3. Test anything you think is a funny special case particularly 'odd' values.

 4. When you find a bug add a unit test that would have revealed that bug and think about whether any similar cases should be added.


For more complex algorithms consider also:

1. Doing some bulk testing of more cases.
2. Using some method of producing random test cases and comparing the result to a 'brute-force' implementation and checking the invariants.

For example check a sorting algorithm with some randomized input and validating the data is sorted at the end by scanning it. 

I'd say your tech lead is proposing 'minimal bare ass' testing. I'm offering 'highest value quality testing' and there's a spectrum in between.

The key lesson is to add tests when bugs are found.