1

Possible Duplicate:
What is Object Mocking and when do I need it?

Why create a mock object using 

MyObject myOb = Mockito.mock(MyObject.class);

When can just use instead : 

MyObject myOb = new MyObject();

    public class MyObject(){
       private String str;
       //getters and setters
    }

If above object becomes more complex & it has dependencies to other object, I need to create mock objects for these also. So if all members are required to be set to test an object, why not just create the object itself instead of mocking it using a framework ?

Community
  • 1
  • 1
blue-sky
  • 51,962
  • 152
  • 427
  • 752
  • 1
    Because https://code.google.com/p/mockito/ describes what Mockito does above plain objects. –  Aug 13 '12 at 11:18
  • 1
    Because mock frameworks offers much more features than plain objects, expressiveness, stubbing, verifications, callbacks, etc. With those, in unit tests you now focus more on the interactions between collaborators, which means you can go further in testing different execution paths, in different scenarios, i.e it helps covering your code. – bric3 Aug 13 '12 at 12:27

3 Answers3

6

Just compare the number of lines you have written in your examples. Sure, you can write all the mocks manually, but you will do a lot more typing, and your tests will be less readable.

Björn Pollex
  • 75,346
  • 28
  • 201
  • 283
  • Also, consider when your objects have 20+ methods but you're only interested in mocking *one* (or a few of them) of them. Creating a mock object: still 1 line, writing it on your own: lots of lines. – Philipp Reichart Aug 13 '12 at 11:31
  • 1
    @Björn Pollex the amount of lines I have written in my examples are the same - one line each – blue-sky Aug 13 '12 at 13:26
  • 1
    Maybe I have misunderstood something. It looked like you where writing the `MyObject`-class specifically for use as a mock. Suppose you require an implementation of an interface for testing, but you don't already have one (for instance a callback you require from users of the library you are writing a test for). This is where mocking can help you. Instead of writing an implementation just for the test, you can let a mocking-framework handle this. This is what I meant in my answer. – Björn Pollex Aug 13 '12 at 13:38
  • @Björn Pollex thanks for clarification. I just wrote the MyObject to show how its implemented. – blue-sky Aug 13 '12 at 13:47
  • +1 for "... tests will be less readable.". I like to be able to read a test, and see all my stubbing (`when(` _something_ `).thenReturn(` _something_ `);`) - and KNOW that it's stubbing; followed by the code that calls whatever's being tested, followed by verifications or assertions (`verify(` _something_ `).something();`), but if I had a whole lot of hand-rolled interactions that are not obviously stubbing and verification, my test would be much harder to understand. – Dawood ibn Kareem Aug 13 '12 at 23:41
2

When you mock something, you can also assert that certain things happen, like you can assert a method was called with parameters etc.

You cant do this using the concrete class

Craig Godden-Payne
  • 235
  • 1
  • 4
  • 3
    You can do this with a concrete class, but you will have to write the logic for it by hand. Mocking frameworks are really just convenience - but **a lot** of it. – Björn Pollex Aug 13 '12 at 11:22
  • you could, but you would have to create a concete class for each scenario. Mocking a class in my opinion is easier, because you only have to mock for the scenario you are testing, other methods, properties etc can be ignored – Craig Godden-Payne Aug 13 '12 at 11:24
1

If you're asking this question, you have never encountered a test-scenario complex enough to need mocking. Of course, if your classes are simple and isolated enough that you can test them by simply instantiating them, you should.

However, in many real-life cases you want to test classes that have dependencies on other classes where it's not possible (or desirable) to instantiate them in a unit-test scenario. It may be that they communicate with external services or databases. It can be that they have a long chain of additional dependencies you would have to instantiate.

Remember also, unit-testing is about isolating specific units of computation and verify that they behave as they should independently. Mocking is a great way of doing this, allowing you to remove dependencies from your tests. Effectivly saying "assuming that dependency A returns Y, verify that this method returns X (and that dependency A is called with these arguments).

pap
  • 27,064
  • 6
  • 41
  • 46