Home > SOLID > The Art of Mocking – Part 2

The Art of Mocking – Part 2

We are back with part 2 of the series, if you haven’t read the first part of the series I recommend please read it in order to see what changes we are going to make to our classes.

First lets start decoupling the CreditHistoryCheck class which calls the public GlobalCreditServices and extract the interface out of this class.

Extract interface

Lets rewrite the CreditHistoryCheck class using the ICreditHistoryCheck interface

CreditHistoryCheck using the interface

Now due to the interface (contract) it is easy to decouple the dependency between the LoanApprovalService class and the CreditHistoryCheck class using constructor injection.

CreditHistoryCheck using the interface

As you can see the LoanApprovalService class depends on the interface and not the concrete class.

Lets apply the same principle to seperate the return resultset (data) from the actual result set so that we can create fake objects and use it in our test.

Result set interfaces

As you can see above we seperated the attributes of CreditResult class into an interface and created a fake object alongside the concrete class.This is where things gets very interesting and the whole concept/debate of fake vs mock objects comes into the developer community.

Now lets write the unit test using the Moq framework and I will explain it to you line by line.( Of course add reference to Moq.dll first 😉 )

Result set interfaces

So in the first line of code we are creating an instance of FakeCreditResult so that when we new up this object we can assert different set of attribute, it’s like we are forcing our fake object to give us a desired result with out modifying our actual object i.e. CreditResult. ( almost the ‘O’ open/close principle of SOLID)

Next line is interesting and the most important of all, this is the first time we are refering to the Moq framework. What it means that we are asking Moq framework to new it’s Mock Object and it takes a generic type of either an interface or abstract class.So we are asking Mock class to return an instance of mock object which is of type ICreditHistory.

In the next line we setup the mock object using the Setup method and use the lamda expression and the expression x=>x.GetCreditHistory means when ever we refer to the mock object just fakely execute the GetCreditHistory method.Also worth notice is that the method signature of the interface ICreditHistory takes an int (social security number) and we are saying :-



   It.IsAny<Int32>()



So what we are saying with this that I don’t care what numeric value you (the ‘Moq’ framework) substitute just simulate to execute the method but after the execution return my fake object i.e. mockCreditResult object.

So in all we created a Mock object ‘mockCreditHistory‘ which holds an internal object and implements the ICreditHistory and when we refer to this internal object it’s GetCreditHistory method will be executed.

Now we can pass this internal object using the mockCreditHistory.Object property to the LoadApprovalService as you remember we decouple the dependency between the 2 class and use constructor injection to pass the ICreditHistoryCheck to the LoanApprovalService.

In the next line we called the service.IsQualifiedForLoan method with a fake parameterand now when we run the test the Asset.IsTrue will return true as the result will always be true.

And this is how the FakeCreditResult class looks like, remember it is just for illustration and not the best way of creating DTOs there are lot of details I have removed from the object for the sake of clarity ( for example no Id’s etc)

Fake Credit Result

And this is final dependency diagram looks like after full refactoring and using SOLID design principles

Final design

As you can I have used both fake objects and mock objects and illustrated how to use each of these approaches and due to the mock object I am not running this test against the actual web service.

Sometimes it’s easy to ignore such finer details but as your projects goes bigger and complex everday you will see the benefit of using such design principles and patterns. Remember what ever I have stated is nothing new it is still good old object oriented design.

Feel free to write comments and please let me know if I need to work on Part 3 as well …

Advertisements
Categories: SOLID Tags: , , , ,
  1. Yogesh
    August 3, 2010 at 1:18 am

    Nice easy to understand style Prashant. Good to see in practice some good old OOD. Even if I’m not doing TDD, this is very useful in unit testing. Part 3 then

    • August 4, 2010 at 2:11 am

      Hi Yogesh,
      Thanks for the feedback and you are write even if you are not using TDD it is still a good pattern to do unit testing and testing in isolation.

      I recommend you to have a look at BizMock mocking framework for BizTalk, as it allows you to mock Biztalk ports and orchestration and could be useful in the long run.

      I also recommend to have a look at the source code and you will see some of the design patterns and SOLID principle used in designing the framework.

  2. August 5, 2010 at 7:24 am

    Excellent article(s) – great introduction – you have inspired me to plan a Mocking version (including IoC) of a TDD tutorial I am working on now.
    Well done
    Dom

    • August 10, 2010 at 2:23 am

      Hi Dom,
      I am glad you liked the blog post and now I’m eagerly looking forward for your tutorial.

      Thanks

      Prashant Brall

  1. August 10, 2010 at 1:43 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: