The difference between Stubs and Mocks

A mock is an object that can set an expected value, which will verify that the desired action has occurred. The stub is the object that you pass to the code under test. You can set expectations on it to work in specific ways, but those expectations are never verified. The stub's properties will automatically behave as standard properties, and you cannot set expectations on them.

If you want to verify the code's behavior under test, a simulation with appropriate expectations is used and validated. If you're going to pass only values that might need to work somehow but are not the focus of the test, you can use stubs.

Important note: Stubs will never cause a test to fail. 

I believe the most significant difference is that you have written the stub with predetermined behavior. Thus, you will have a class that implements the dependencies that you have disguised for testing purposes (most likely an abstract class or interface), and a class will handle the method only through the response that is set. They don't do anything fancy, and you've already written stub code for them outside of testing.

Simulations are expectations that stubs must set during testing. The simulation is not set up in a predetermined way, so you have the code to perform the simulation in your tests. The mockery is determined at run time because the code that sets expectations must be run before they do anything.

The difference between stubs and stubs

Tests written with simulation usually follow a test pattern of initialize-> set expectations -> exercise -> verify. The pre-written stub will be followed by an initialize-> exercise-> verify.

Similarities between stubs and stubs

The purpose of both is to remove all dependencies from testing a class or function so that your tests are more focused and straightforward when trying to prove it.

The most crucial difference between Stubs and Mocks is their intention. Explain this in the WHY stub and WHY simulation below

Suppose I'm writing test code for the Mac Twitter client's public timeline controller

Here is the sample code for the test：

twitter_api.stub(:public_timeline).and_return(public_timeline_array)

client_ui.should_receive(:insert_timeline_above).with(public_timeline_array)

controller.refresh_public_timeline

Stub: The network connection to the Twitter API is very slow, which makes my tests slow. We knew it would return the timeline, so we made a stub that simulated the HTTP Twitter API so that our test could sprint, even if I were offline.

Mock: We haven't written any UI methods yet, and I'm not sure what we need to register for UI objects. We wanted to write test code to see how my controller would work with UI objects.

In short, there is a difference between Mock and Stub objects, and RhinoMocks recognize that they allow us to write tests that better illustrate their purpose. The mock object is used to define the expectation that, in this case, I want to call the method A () with such an argument. Record and verify this expectation with ridicule. On the other hand, Stubs have a different purpose: they do not record or validate expectations but rather allow us to "replace" the behavior and state of "fake" objects to take advantage of test scenarios.

https://martinfowler.com/articles/mocksArentStubs.html

https://medium.com/swlh/what-is-the-difference-between-a-mock-and-a-stub-bd6b639e9fa5