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:
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:
[TestMethod]
public void CreateRoomType()
{
var repository = MockRepository.GenerateMock<IRoomTypeRepository>();
var roomType = new RoomType();
repository.Expect(x => x.Save(roomType));
var service = new RoomTypeService(repository);
service.CreateRoomType(roomType);
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.