Unit Testing Using Rhino mock

Question

0.00/5 (No votes)

See more:

Hi,
I am new to unit testing. After going through the internet I decided to use rhino mock for unit testing. I am using repository and uow pattern in my project. Now let me start from my controller class. I have like this

C#

private readonly IRoomTypeService _roomTypeService;

       public RoomTypeController(IRoomTypeService roomTypeService)
       {
           this._roomTypeService = roomTypeService;
       }

       public RoomTypeController()
       {

       }

Now my service interface class is like below

C#

 public interface IRoomType : IEntityRepository<RoomType>
    {
    }

Repository class something like this
 public class RoomTypeRepository : EntityRepositoryBase<RoomType>, IRoomType
    {
        public RoomTypeRepository(IDBFactory databaseFactory)
            : base(databaseFactory)
        {
        }

Everything works fine when I run the application but while doing unit test using rhino mocks I couldn't get data nor save data into database.

C#

private IRoomType roomTypeRepositoryMock { get; set; }
       private IUnitOfWork uowRepositoryMock { get; set; }

       [TestInitialize]
       public void Initialize()
       {
           roomTypeRepositoryMock = MockRepository.GenerateMock<IRoomType>();
           uowRepositoryMock = MockRepository.GenerateMock<IUnitOfWork>();
       }


       [TestMethod]
       public void InsertRoomType()
       {


           RoomType roomType = new RoomType()
           {
               RoomType1="R1",
               NoofBeds=2,
               IsTVAvailable=false,
               IsACAvailable=false,
               OtherFacilitiesAvailable="NA"
           };

           var roomTypeService = CreateRoomTypeService();
           roomTypeService.CreateRoomType(roomType);

       }

       private RoomTypeService CreateRoomTypeService()
       {
           return new RoomTypeService(roomTypeRepositoryMock, uowRepositoryMock);
       }
   }

With basic ideas on unit testing I have done this code. Could any one help me to solve this issue.

Posted 12-Jan-15 2:41am

Mithun P

Updated 12-Jan-15 2:45am

CHill60

v4

Add a Solution

Comments

George Swan 13-Jan-15 2:22am

As it stands, your test does not actually test anything. You need to Assert (test) that some value is correct or that a certain method has been called. Unit tests should run entirely in memory and not rely on external services such as a database. A useful technique is to fake the database and to test that the values passed to it are correct. In effect, you are testing how your program relates to the database rather than testing the database itself. It’s good to keep the statements simple so as not to introduce bugs into the test.

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Tomas Takac · Accepted Answer · 2015-01-13T02:43:00

The problem is you didn't specify what the mocks should do. The purpose of a mock in a unit test is to provide a known environment for the test. The point is you need invariant inputs so you can then compare the outputs to your expectations.

Let's assume you want to test the CreateRoomType() method of RoomTypeService. I will simplify your code a bit here. But you didn't show the relevant parts there anyway:

C#

public interface IRoomTypeRepository
{
    void Save(RoomType roomType);
}

public class RoomTypeService
{
    private readonly IRoomTypeRepository _repository;

    public RoomTypeService(IRoomTypeRepository repository)
    {
        _repository = repository;
    }

    public void CreateRoomType(RoomType roomType)
    {
        _repository.Save(roomType);
    }
}

In order to test the method we need to supply the repository instance. This will be the mock of course, you figured that much by yourself already. Now think of what are you trying to achieve, what's the objective of your test? We need to check that the roomType instance get's saved to the repository. We need to prepare the mock in such way that we can verify this was done. I like to write my test in following format:

C#

[TestMethod]
public void CreateRoomType()
{
    // arrange
    var repository = MockRepository.GenerateMock<IRoomTypeRepository>();
    var roomType = new RoomType();
    repository.Expect(x => x.Save(roomType));
    var service = new RoomTypeService(repository);

    // act
    service.CreateRoomType(roomType);

    // assert
    repository.VerifyAllExpectations();
}

Note the Expect method call on the repository. This way we let rhino mocks know we want to check the call to the Save() method (with the exact instance of roomType). We then evaluate this expectations at the end when calling VerifyAllExpectations() on the repository mock. Now try to comment out the call to _repository.Save() in the service class - the test should fail.

This is of course trivial. But imagine there is a lot more logic in the service. Generally you only want to test one functionality at a time. This means limiting the expectations and using stubs for other method calls. If you'd use expectations everywhere your test would be too tightly coupled to the internals of the tested class hence easy to break and hard to maintain. In my experience this is especially true when you are mocking unit of work.