I generally feel the highest value tests are at the lowest level (code with few dependencies) as well as end-to-end integration tests. It gets a little murkier in middle layers since alternate implementations of dependencies (aka mocks) need to be created, or one has to deal with complex setup of dependencies or in some cases re-testing the same logic that has already been tested at a lower level.

I'm not suggesting middle layer testing is not valuable, shouldn't be done, or to never use mocks, etc., it is just much more difficult and more creativity is required to add value in this area. For example, in some situations middle layer testing requires the creation of various kinds of utilities and frameworks in order to find a reasonable benefit vs effort sweet spot. Dogmatic approaches (such as mocking all dependencies in all situations) feel like they are productive at first but can end up being costly as each mock is an alternate implementation of an interface and doesn't necessary capture the behaviour of the concrete implementation.

I hardly ever do unit testing. It's almost always integration testing with code that uses real implementations against a testing db. This is only possible because my code is decoupled in the right places to enable this sort of no mock style testing.

I don't strive for 100% coverage and I hardly ever do TDD unless I'm working on something hard to solve.

Tests give me confidence and results in less time repeating the feedback loop. I might have a slower "coding speed" but I have fewer regressions during refactoring. Less bugs to fix while iterating. And less back and forth with stakeholders to ship something. Overall I'm way faster with tests than without.

This is the advice I give to junior developers:

1. Feel free to write tests that help you develop your thought or solution. Not all of those should be checked in

2. Ask yourself: “What test do you need to write in order to protect this code from your future self next year when you have forgotten everything about this?”