What is Mocking?

问题:

What is Mocking?                                                                                                    .

回答1:

Prologue: If you look up the noun mock in the dictionary you will find that one of the definitions of the word is something made as an imitation.

---

Mocking is primarily used in unit testing. An object under test may have dependencies on other (complex) objects. To isolate the behavior of the object you want to replace the other objects by mocks that simulate the behavior of the real objects. This is useful if the real objects are impractical to incorporate into the unit test.

In short, mocking is creating objects that simulate the behavior of real objects.

---

At times you may want to distinguish between mocking as opposed to stubbing. There may be some disagreement about this subject but my definition of a stub is a \"minimal\" simulated object. The stub implements just enough behavior to allow the object under test to execute the test.

A mock is like a stub but the test will also verify that the object under test calls the mock as expected. Part of the test is verifying that the mock was used correctly.

To give an example: You can stub a database by implementing a simple in-memory structure for storing records. The object under test can then read and write records to the database stub to allow it to execute the test. This could test some behavior of the object not related to the database and the database stub would be included just to let the test run.

If you instead want to verify that the object under test writes some specific data to the database you will have to mock the database. Your test would then incorporate assertions about what was written to the database mock.

回答2:

Other answers explain what mocking is. Let me walk you through it with an example. And believe me, it\'s actually far more simpler than you think.

tl;dr It\'s a subclass of the original class. It has other data injected into so you avoid testing the injected parts and solely focus on testing the rest of the code.

---

Let\'s say you are writing an iOS application and have network calls.Your job is to test your application. To test/identify whether or not the network calls work as expected is NOT YOUR RESPONSIBILITY . It\'s another party\'s (server team) responsibility to test it. You must remove this (network) dependency and yet continue to test all your code that works around it.

A network call can return different status codes 404, 500, 200, 303, etc with a JSON response.

Your app is suppose to work for all of them (in case of errors, your app should throw its expected error). What you do with mocking is you create \'imaginary—similar to real\' network responses (like a 200 code with a JSON file) and test your code without \'making the real network call and waiting for your network response\'. You manually hardcode/return the network response for ALL kinds of network responses and see if your app is working as you expect. (you never assume/test a 200 with incorrect data, because that is not your responsibility, your responsibility is to test your app with a correct 200, or in case of a 400, 500, you test if your app throws the right error)

This creating imaginary—similar to real is known as mocking.

In order to do this, you can\'t use your original code (your original code doesn\'t have the pre-inserted responses, right?). You must add something to it, inject/insert that dummy data which isn\'t normally needed (or a part of your class).

So you subclass the original class and add whatever (here being the network HTTPResponse, data OR in the case of failure, you pass the correct errorString, HTTPResponse) you need to it and then \'test the subclass\' ie the mocked class.
_{You no longer test the original class. The mocked/subclass is tested on behalf of the original class}

Long story short, mocking is to simplify and limit what you are testing and also make you feed what a class depends on. In this example you avoid testing the network calls themselves, and instead test whether or not your app works as you expect with the injected outputs/responses —— by mocking classes

_{Needless to say, you test each network response separately.}

---

Now a question that I always had in my mind was: The contracts/end points and basically the JSON response of my APIs get updated constantly. How can I write unit tests which take this into consideration?

To elaborate more on this: let’s say model requires a key/field named username. You test this and your test passes. 2 weeks later backend changes the key\'s name to id. Your tests still passes. right? or not?

Is it the backend developer’s responsibility to update the mocks. Should it be part of our agreement that they provide updated mocks?

The answer to the above issue is that: unit tests + your development process as a client-side developer should/would catch outdated mocked response. If you ask me how? well the answer is:

Our actual app would fail (or not fail yet not have the desired behavior) without using updated APIs...hence if that fails...we will make changes on our development code. Which again leads to our tests failing....which we’ll have to correct it. (Actually if we are to do the TDD process correctly we are to not write any code about the field unless we write the test for it...and see it fail and then go and write the actual development code for it.

This all means that backend doesn’t have to say: “hey we updated the mocks”...it eventually happens through your code development/debugging.‌ّ Because it’s all part of the development process! Though if backend provides the mocked response for you then it\'s easier.

My whole point on this is that it\'s inefficient to come up with some script to get an updated mock of your APIs. Neither is TDD about placing 100% of your effort on getting things done automatically and void of any human interaction. Part of the process is manual updates of JSONs and having short meetings to make sure their values are up to date.

_{This section was written thanks to a slack discussion in our CocoaHead meetup group}

---

For iOS devs only:

A very good example of mocking is this Practical Protocol-Oriented talk by Natasha Muraschev Just skip to minute 18:30.

I really like this part from the transcript:

Because this is testing...we do want to make sure that the get function from the Gettable is called, because it can return and the function could theoretically assign an array of food items from anywhere. We need to make sure that it is called;

回答3:

There are plenty of answers on SO and good posts on the web about mocking. One place that you might want to start looking is the post by Martin Fowler Mocks Aren\'t Stubs where he discusses a lot of the ideas of mocking.

In one paragraph - Mocking is one particlar technique to allow testing of a unit of code with out being reliant upon dependencies. In general, what differentiates mocking from other methods is that mock objects used to replace code dependencies will allow expectations to be set - a mock object will know how it is meant to be called by your code and how to respond.

---

Your original question mentioned TypeMock, so I\'ve left my answer to that below:

TypeMock is the name of a commercial mocking framework.

It offers all the features of the free mocking frameworks like RhinoMocks and Moq, plus some more powerful options.

Whether or not you need TypeMock is highly debatable - you can do most mocking you would ever want with free mocking libraries, and many argue that the abilities offered by TypeMock will often lead you away from well encapsulated design.

As another answer stated \'TypeMocking\' is not actually a defined concept, but could be taken to mean the type of mocking that TypeMock offers, using the CLR profiler to intercept .Net calls at runtime, giving much greater ability to fake objects (not requirements such as needing interfaces or virtual methods).

回答4:

Mock is a method/object that simulates the behavior of a real method/object in controlled ways. Mock objects are used in unit testing.

Often a method under a test calls other external services or methods within it. These are called dependencies. Once mocked, the dependencies behave the way we defined them.

With the dependencies being controlled by mocks, we can easily test the behavior of the method that we coded. This is Unit testing.

What is the purpose of mock objects?

Mocks vs stubs

Unit tests vs Functional tests

回答5:

The purpose of mocking types is to sever dependencies in order to isolate the test to a specific unit. Stubs are simple surrogates, while mocks are surrogates that can verify usage. A mocking framework is a tool that will help you generate stubs and mocks.

EDIT: Since the original wording mention \"type mocking\" I got the impression that this related to TypeMock. In my experience the general term is just \"mocking\". Please feel free to disregard the below info specifically on TypeMock.

TypeMock Isolator differs from most other mocking framework in that it works my modifying IL on the fly. That allows it to mock types and instances that most other frameworks cannot mock. To mock these types/instances with other frameworks you must provide your own abstractions and mock these.

TypeMock offers great flexibility at the expense of a clean runtime environment. As a side effect of the way TypeMock achieves its results you will sometimes get very strange results when using TypeMock.

回答6:

I would think the use of the TypeMock isolator mocking framework would be TypeMocking.

It is a tool that generates mocks for use in unit tests, without the need to write your code with IoC in mind.

回答7:

Mocking is generating pseudo-objects that simulate real objects behaviour for tests

回答8:

If your mock involves a network request, another alternative is to have a real test server to hit. You can use this service to generate a request and response for your testing. http://testerurl.com/