aspose file tools*
The moose likes Testing and the fly likes Practical Testing with TestNG and Mockito Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Engineering » Testing
Bookmark "Practical Testing with TestNG and Mockito" Watch "Practical Testing with TestNG and Mockito" New topic
Author

Practical Testing with TestNG and Mockito

paul nisset
Ranch Hand

Joined: May 13, 2009
Posts: 177
Hi,

From reading some of the other questions ,I understand that TestNG is meant to be sued as a replacement for JUNit .
How does Mockito play into it ? Is it meant to be imported to create proxy objects to be used by the unit test ?

I'm not sure if I am using Junit correctly but I usually create a mock/proxy object of the class for each method I'm testing .

Thanks,
Paul


Tomek Kaczanowski
author
Ranch Hand

Joined: Oct 26, 2005
Posts: 40

Hi Paul,

paul nisset wrote:
From reading some of the other questions ,I understand that TestNG is meant to be sued as a replacement for JUNit .

Yes, exactly.

paul nisset wrote:
How does Mockito play into it ? Is it meant to be imported to create proxy objects to be used by the unit test ?
I'm not sure if I am using Junit correctly but I usually create a mock/proxy object of the class for each method I'm testing .

Paul, I don't understand what you mean by "proxy objects" in relation to testing. What Mockito allows you to do, is to replace real collaborators of a class, so during the tests we can:

* control their behaviour, in particular, control the values they return to the tested object (or make them throw some exceptions), which allows us to exercise all the logic implemented within the tested object
* verify that they receive specific, expected messages from the tested objects (or in other words, verify that some of their methods were called with expected arguments) - this allows us to make sure that the tested object interacts in the right way with its collaborators.


Tomek Kaczanowski
Book author: Practical Unit Testing with TestNG and Mockito
http://practicalunittesting.com
paul nisset
Ranch Hand

Joined: May 13, 2009
Posts: 177
Thanks Tomek.
Your description of collaborators was what I meant by proxy objects.
What I've been doing is doing is creating an object manually (in the method that I'm testing) ,initializing it's properties and then using it (in the method that i'm testing).
I guess I don't see the advantage of using a framework to doing this.

Suppose I have a ValidatePerson object that I'm testing and one of it's methods is checkNameLength().

The JUnit test method might look like:



In this case the test would pass because "john" is longer than 2.
I'm not seeing how a framework ,Mockito or something else, would simplify this.

Is Mockito meant to be used in a different way or a different scenario?

thanks,
Paul
Tomek Kaczanowski
author
Ranch Hand

Joined: Oct 26, 2005
Posts: 40

Hi Paul,

your approach will work for simple cases. But even with such simple cases you would encounter issues, that can be easily avoided when using a mocking framework (Mockito or anything else). Please note, that your tests is tightly coupled with the implementation of two classes - ValidatePerson and Person. And this is one too many (Single Responsibility Principle for test code says that it should have "one and only one reason to fail") . You need to change your test code with every change made to Person's constructor. Using Mockito, such changes are completely irrelevant, and you don't have to change anything.

Things get much worse if you move from such simple cases to more complex ones. "Mocking by hand" approach will not be sufficient (and efficient) anymore. Consider the following examples (by collaborator I mean a class like Person from your example):

* a collaborator is an interface with many methods
* a collaborator is not a simple class with getters/setters (or fields set by constructors) - some values required by tests are computed within this class and you can not easily make collaborator return desired values (maybe the computed results depend on time, maybe on external web services, etc. etc.)
* a collaborator can throw many exceptions, which should be taken into account when testing all logic paths of the tested class

Yes, you could solve all of them writing mocks by hand but... do you really have time for this? Would you be happy with your tests code polluted with long implementation of interfaces (and remember you need few of them to test every possible scenario)? It would require many lines of code, and your tests would be very brittle - you would have to change them significantly if any change in collaborator class occurs.

Yes, you can do it by hand, but sooner or later you will write your own mocking framework to avoid pains related to testing of the scenarios mentioned above.
paul nisset
Ranch Hand

Joined: May 13, 2009
Posts: 177
Thank you for your explanation Tomek .
This is useful .

I can see how it does make sense to use a mocking framework for the scenarios you described.

Cheers.
Paul

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Practical Testing with TestNG and Mockito