I think this article explains really well: martinfowler.com/articles/mocksArentStubs.html The article is long, but it has lots of interesting discussions. In particular these two: Design Style and Coupling Tests to Implementations which I felt first hand in the projects/companies I've worked for in the past

Anyway, the main point for me in the discussion about Stubs vs Mocks is:

there is a difference in how test results are verified: a distinction between state verification and behavior verification.

I fit in what Fowler calls the classical approach I find it easier to just care about the final state of test (and not how this state was derived). He sums it pretty well:

With mockist testing, writing the test makes you think about the implementation of the behavior - indeed mockist testers see this as an advantage.

Classicists, however, think that it's important to only think about what happens from the external interface and to leave all consideration of implementation until after you're done writing the test.

And in fact that is exactly what I do (think what happens from outside), it just happens to be natural for me to think that way.

Stub

I believe the biggest distinction is that a stub you have already written with predetermined behavior. So you would have a class that implements the dependency (abstract class or interface most likely) you are faking for testing purposes and the methods would just be stubbed out with set responses. They would not do anything fancy and you would have already written the stubbed code for it outside of your test.

Mock

A mock is something that as part of your test you have to setup with your expectations. A mock is not setup in a predetermined way so you have code that does it in your test. Mocks in a way are determined at runtime since the code that sets the expectations has to run before they do anything.

Difference between Mocks and Stubs

Tests written with mocks usually follow an initialize -> set expectations -> exercise -> verify pattern to testing. While the pre-written stub would follow an initialize -> exercise -> verify.

Mocks are instantiations of real object in your system, complete with all the necessary plumbing and expected functionality of that real object. I will use a mock API endpoint (an instantiation of a real API endpoint that doesn't actually affect other systems/data) that responds appropriately to a given input (i.e. returns an error, returns the expected object).

Stubs are incomplete. I use stubs to fake something that I don't know exactly what it needs to be, yet. I frequently will create stub API end points that are only designed to return a canned response, while I figure out what I actually need from the API I have yet to build.

To put it another way:

A mock is a fake based on something that actually exists in your system or application.

A stub is a fake based on something that either does not exist in the necessary state, that you do not need actual business logic of, or a place holder until other code is completed.

It's possible I'm just not good enough at unit testing, but I've long felt there are needlessly many names for test objects: dummy, fake, stub, mock, spy.

If you're actually writing a test and need to replace some complex dependency, it's fairly obvious how much your fake version should and should not do, what it should return and whether it should register calls somehow.

So my suggestion would be to not waste too much energy on names, and just write the tests. Names can be useful when communicating with other people, but in this case everyone either doesn't know or disagrees, so it's a useless distinction.

We programmers are just not great at naming things.

To be able to help you, can you please share the tools and languages you're interested in? Are you interested in using Sinon.js maybe?