Unit testing is definitely the best way for developers to test their code. As described at length elsewhere, unit testing allows software engineers to write a function or a unit of code and test that unit specifically; no need yet for front end, user testing.
I would argue though, that over reliance on unit testing leads to bugs in other places in your application.
For instance if your company has a complex web application, with an API layer in the backend that responds to requests from the front end, you may have clearly structured your API layer to reuse components as much as possible. So you may end up having one API endpoint that calls out to other internal API endpoints, rather than doing their own leg work to call the database. This is good practice, since you can maintain one endpoint service across your API layer. But what if the API contract changes for that endpoint, that is called from 5-10 other endpoints. You may think great I’ll just update all those endpoints to use the new model of data that is being returned by the updated API endpoint. But what if you don’t know how many endpoints are calling that endpoint because you are only focused on unit testing your little piece of the pie? You update an endpoint with the new model of data being returned, and only update the one other controller that was calling your old API. Now you may end up with a bunch of other API endpoints that will only error out when they are called. If those other old endpoints are part of your frontend that isn’t used much, you might have a bunch of bugs just waiting there to be discovered, but you won’t ever know about that because you’ve relied heavily on unit testing, rather than taking an application wide emphasis on testing.
Ideally, I would argue, that any time one endpoint is updated in your application, all endpoints need to be called and exceptions raised for any endpoints that may have been unintentionally impacted by the change to that first endpoint. Most importantly, these universal API endpoint tests need to be automated with corresponding sample data based on models for endpoints that expect input. Any changes in the expected endpoint read/write responses need to be logged and exceptions raised.
This seems obvious: why wouldn’t you have an automated test suite for API endpoints? Yes, that’s true, but I would argue, it is often overlooked by most small to medium size companies that do not have an entire team dedicated to testing and QA. Not universally testing all API endpoints as part of your CI/CD pipeline is a massive risk in your software development lifecycle.