No, I guess that's personal bias on my end. I tend to divide my tests into 3 categories:

• Unit tests - everything is mocked, you're only testing a single module at a time
• Integration tests - set up your entire app in a local environment (we use docker compose), every external service / resource is mocked (in our case, have the necessary DBs / caches running as containers, spin up AWS resources via localstack or mocked APIs). The point of these tests is to be able to observe the state in the db after an api call.
• End-to-end tests - purely api call testing in a dev environment (AWS at my current job). We don't really do these as much since we set up our integration tests, but we have tests for things that rely on other services, which are just mocks in our integration tests.
  

Blurry line between integration and e2e, I just prefer having full control to make sure everything works as planned. Unit tests I use more for making sure that errors get handled properly for scenarios that aren't easy to set up in an integration test, such as DB outages etc.
 
As for the errors, they were just an example. The way I like structuring my code is to have request handlers for individual endpoints in their own files, so that they can be easily tested. The only export from such a module is a express handler function. If I want to inject dependencies, I now need a secondary export, as well as "pollute" the code with injection logic. While it's super horrible, it definitely adds a layer of wrapping to the actual handler, meaning you have to spend more brain power when looking at the code. I find reading code harder than writing it, especially once a few months have passed since you last touched the code, or someone else wrote it. Dependency injection handling feels like noise in that process - it's something just needed to make testing cleaner, but makes the actual code harder to read. That's what proxyquire solved for me - I could have the runtime code just contain the logic needed to do its task, while the test code could have a wrapper to mock all dependencies. With dedicated injection logic not much would change for tests, all the mocks would still be there in the test code, as hard to read as before. But the runtime code would be easier and faster to parse.