Comments by "" (@retagainez) on "Thoughts About Unit Testing | Prime Reacts" video.

@epiicSpooky Agreed. And to some extent the hunting is an indicator that there's a poor design/missing coverage in the unit tests. If you start with integration test, you have the highest chance of writing a test case as close as possible to the user's intention.
2
@HrHaakon I think it's just a bunch of misnomers, but if you describe the behavior of the test double, the context makes it easy to find out whether it's a stub or a fully fledged mock object.
1
You don't need a mock object, but you easily could've written a Fake implementation of a database, like an in-memory database class, to accomplish this. That way, you can test the implementation of user validation and database operation without changing production code and then start writing new unit tests for new functionality. A mock would be overkill.
1
So this explains you don't necessarily need a mock object (or to an even larger extent, a mock library) to achieve testing. You can stub, fake, spy. Mock objects are usually much more involved (and nowadays generated by libraries using reflection). Again, mock objects are more involved because they're mimicking behavior of an actual API. They're really not necessary, that should just be an integration test. Just create a better design by abstracting away your external APIs and substitute them with smaller test doubles for unit testing. Unfortunately, as other comments mention, this makes a poor design where your test is tightly coupled to something still. So, if you're highly dependent on a certain protocol's response that overall indicates poor design and is an important portion of the code to minimize that impact.
1