I'm fairly new to testing. Joined an existing project where the guy who wrote the code has left the company and now us who maintain don't have an entire system knowledge. And of course, there are no tests to easily understand what's happening in the code. So now when we change a part of the code either for bugfix or feature change we first reverse engineer tests so we have confidence we don't have regressions.
I find that for this existing system it's better to use the real DB for testing a.k.a make integration tests. I write down that does this feature X do. Then test each of the functionality instead of just mainly worrying about a particular function.
Example, have a function that deletes a user, but the user model in a database has set up a cascade delete on different tables. I need to run it against the database to sure it gets deleted as of a "side-effect". As just reading the tested code won't make it obvious what is happening on the database level. For each test, I first created test records written in the database, then call the function in testing, then assert results and clean the records. With this setup, if the assertion fails the data isn't cleaned, I didn't want to create nested describe scopes with before/after for each separate test. But when looking at the test I can easily see that is going on there without scrolling.
But mocking has its place for working with 3rd-party libraries where you can't call them.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.