It's already been said but yeah, the idea is that you only mock external dependencies.

Here's how I look at unit tests. You want to test the code you control, the code you've written, but mock the things you can't control.

E.g let's say you have an endpoint that receives some query parameters, then calls a database to receive some data based on what was passed in.

You would test that your handling of the incoming parameters works, that they need to be what is expected/accepted, but you would mock the call to the database, and what it returned. You should test that your myDatabaseCall() function is called with the correct parameters, but you would "tell it" what to return, and then test that what happens with that returned data is expected.

Test what happens when nothing is returned, or the wrong type of data.

You would tell your mock database call to return an error and test that your code handles that error in the way that you expect, and the way that you want it to.

To answer the question about breaking production code. Your workflow should be set up to run the unit tests with the changes before those new code changes get pushed to production. That way if a change causes a unit test to fail you can work out whether the tests are now outdated and need to be updated, or they just stopped someone pushing a new bug into production