Mocks and stubs are both dummy implementations of objects the code under test interacts with. The same object may be replaced with a stub in one test and a mock in another depending on the intent of the test.
Stubs can be thought of as inputs to the code under test. When called they behave a certain way – return a fixed value, throw an exception, calculate a return value based on parameters, pull from a sequence of values, etc. You'd use a stub to simulate the collaborator behavior that drives the behavior of the code under test. For example, if your code queries a database using a DAO you might supply a stub DAO and have tests that verify the behavior when your code finds one result, multiple results, zero results or when the query fails with an exception. Stubs provide the condition that prompts the different behavior in your code but they're not the way you verify that behavior.
Mocks can be thought of as outputs from the code under test. Under certain circumstances your code should or should not interact with a collaborator or should interact with it in a specific way – pass certain parameters, call multiple times, call methods in a certain order, etc. The simplest example is an asynchronous method that accepts a callback parameter. With a synchronous methodthat just returned a value, you'd simply check that return value. With an asynchronous version, you can pass a mock callback and verify the value passed to it.
Fake
Fakes are objects that have working implementations, but not same as production one. Usually they take some shortcut and have simplified version of production code.
An example of this shortcut can be an in-memory implementation of Data Access Object or Repository. This fake implementation will not engage database but will use a simple collection to store data. This allows us to do integration test of services without starting up a database and performing time-consuming requests.
Stub
Stub is an object that holds predefined data and uses it to answer calls during tests. It is used when we cannot or don’t want to involve objects that would answer with real data or have undesirable side effects.
An example can be an object that needs to grab some data from he database to respond to a method call. Instead of the real object, we introduced a stub and defined what data should be returned.
Mock
Mocks are objects that register calls they receive. In test assertion, we can verify on Mocks that all expected actions were performed.
We use mocks when we don’t want to invoke production code or when there is no easy way to verify, that intended code was executed. There is no return value and no easy way to check system state change.
References:
https://www.quora.com/Software-Testing-What-is-the-difference-between-Mocks-and-Stubs
https://blog.pragmatists.com/test-doubles-fakes-mocks-and-stubs-1a7491dfa3da
Stubs can be thought of as inputs to the code under test. When called they behave a certain way – return a fixed value, throw an exception, calculate a return value based on parameters, pull from a sequence of values, etc. You'd use a stub to simulate the collaborator behavior that drives the behavior of the code under test. For example, if your code queries a database using a DAO you might supply a stub DAO and have tests that verify the behavior when your code finds one result, multiple results, zero results or when the query fails with an exception. Stubs provide the condition that prompts the different behavior in your code but they're not the way you verify that behavior.
Mocks can be thought of as outputs from the code under test. Under certain circumstances your code should or should not interact with a collaborator or should interact with it in a specific way – pass certain parameters, call multiple times, call methods in a certain order, etc. The simplest example is an asynchronous method that accepts a callback parameter. With a synchronous methodthat just returned a value, you'd simply check that return value. With an asynchronous version, you can pass a mock callback and verify the value passed to it.
Fake
Fakes are objects that have working implementations, but not same as production one. Usually they take some shortcut and have simplified version of production code.
An example of this shortcut can be an in-memory implementation of Data Access Object or Repository. This fake implementation will not engage database but will use a simple collection to store data. This allows us to do integration test of services without starting up a database and performing time-consuming requests.Stub
Stub is an object that holds predefined data and uses it to answer calls during tests. It is used when we cannot or don’t want to involve objects that would answer with real data or have undesirable side effects.
An example can be an object that needs to grab some data from he database to respond to a method call. Instead of the real object, we introduced a stub and defined what data should be returned.
Mock
Mocks are objects that register calls they receive. In test assertion, we can verify on Mocks that all expected actions were performed.
We use mocks when we don’t want to invoke production code or when there is no easy way to verify, that intended code was executed. There is no return value and no easy way to check system state change.
References:
https://www.quora.com/Software-Testing-What-is-the-difference-between-Mocks-and-Stubs
https://blog.pragmatists.com/test-doubles-fakes-mocks-and-stubs-1a7491dfa3da
No comments:
Post a Comment
I'm certainly not an expert, but I'll try my hardest to explain what I do know and research what I don't know.