# Getting started with Unit Testing and Moq Part 2

In the previous post I started exploring unit testing, specifically with moq and for WCF services. Thus far, we have only implemented basic unit tests for a piece of code with no external dependencies, which needed no mocking.

This time, I’m going to explore mocking and testing objects relying on the IDbGetSomeNumbers and INumberFunctions interfaces. As a reminder, those interfaces and corresponding classes are defined as:

And the class utilizing them:

In the constructor, I’m taking in an implementation of both IDbGetSomeNumbers and INumberFunctions. I am doing this, as they are not dependencies for the functionality of the class, and as such their implementation is not important. Rather, it is important, but not for the testing of this class. As the unit testing definition stated: Unit testing is a software development process in which the smallest testable parts of an application, called units, are individually and independently scrutinized for proper operation.

So the interface implementations do need testing (which was already done), they however do not need testing from GetNumbersAndAddThems concern. The only thing that needs testing from this concern, are that the class is constructed properly, and that Execute “gets numbers from the db” and then “adds them”.

Since I’m using the class constructor to take in the class dependencies:

The first things we can test for are that dbGetSomeNumbers and numberFunctions are not null. This can be accomplished as such:

Now for testing Execute we can finally get to Moq! Mocking goes hand in hand with unit testing, as one definitionof mocking states:

It is difficult to test error conditions and exceptions with live, system-level tests. By replacing system components with mock objects, it is possible to simulate error conditions within the unit test. An example is when the business logic handles a Database Full exception that is thrown by a dependent service.

So because the implementation of IDbGetSomeNumbers and INumberFunctions do not matter, we would not want to (necessarily) use their real implementations. This is because they could potentially impact the system or data, which we wouldn’t want to do, as we plan on running these tests at every build… and editing application data at every build would be… bad. Anyway, with mocking we can tell the interfaces upon being invoked, to return a specific response. This means we can make the Execute functionality use completely mocked implementations of their dependencies, just test the the function Execute takes in and passes back the appropriate types of values. Mocking setup:

The fields _mockNumberFunctions and _mockIDbGetSomeNumbers are set up as Mock<interface>. In Setup we’re just simply newing them up. Now to the good parts, the tests utilizing the mocks:

In _mockIDbGetSomeNumbers.Setup(…).Returns(…) We’re stating that when the GetSomeNumbers() function is called, it needs to return numbersToUse. Pretty fancy! Rather than relying on our concrete implementation of IDbGetSomeNumbers which has to go out to the database, we’re telling it to use this defined list of numbers that have been spelled out by the setup of the mock. Now we can with absolute certainty say what the sum of the numbersToUse will be, because we know what numbers will be provided each time since they aren’t being pulled from the database. Hopefully that all makes sense. Makes sense to me anyway! :O

Next time I hope to get into WCF creation and testing.