I have mvc application and I'm working with poco objects and writing unit test. Problem is that all my test fail when they reach this line of code Roles.IsUserInRole("someUser", "role"). Should I implement new interface or repository for Roles or...?
Thx
I had the same problem when trying to mock the Roles.IsUserInRole functionality in my coded unit tests. My solution was to create a new class called RoleProvider and an interface with method IsUserInRole which then called the System.Web.Security.Roles.IsUserInRole:
public class RoleProvider: IRoleProvider
{
public bool IsUserInRole(IPrincipal userPrincipal)
{
return System.Web.Security.Roles.IsUserInRole(userPrincipal.Identity.Name, "User");
}
}
Then in my code I call the RoleProvider IsUserInRole method. As you have an interface you can then mock the IRoleProvider in your tests, example shown here is using Rhino Mocks:
var roleProvider = MockRepository.GenerateStub<IRoleProvider>();
roleProvider.Expect(rp => rp.IsUserInRole(userPrincipal)).Return(true);
Hope this helps.
You can set up a custom method to check roles that will behave differently in tests, but I prefer to have the tests set up a context that will work with the standard methods.
http://stephenwalther.com/blog/archive/2008/07/01/asp-net-mvc-tip-12-faking-the-controller-context.aspx
You could create a light wrapper with a Predicate/Func.
public static Predicate<string> IsUserInRole = role => Roles.IsUserInRole(role);
Then use IsUserInRole() instead of Roles.IsUserInRole(). At run time you get the same behavior. But at test time you can override the function so that it doesn't access the RoleProvider
MyClass.IsUserInRole = role => true;
If you prefer to not have a public static you could inject the Predicate via your constructor and store it as a private readonly.
class MyClass
{
private readonly Predicate<string> IsUserInRole;
MyClass(Predicate<string> roleChecker) { this.IsUserInRole = roleChecker }
MyClass() : this(role => Roles.IsUserInRole(role)) { }
}
If you use Moq you can return a mock and then control the return value and/or check the method was called. And check what parameter value was sent to the Predicate.
Mock<Predicate<string>> mockRoleChecker = new Mock<Predicate<string>>();
var cut = new MyClass(mockRoleChecker.Object);
var expectedRole = "Admin";
mockRoleChecker.SetReturnsDefault<bool>(true); // if not specified will return false which is default(bool)
cut.MyMethod();
mockRoleChecker.Verify(x => x(expectedRole), Times.Once());
Related
I can make it work, but I want to know what the best practice is and why. I have a Controller, a Model, and a Repository and now I want to Unit Test the Controller. I am just writing a simple test to ensure that the correct view is being returned.
This is my method in the controller:
public ActionResult Selections(SelectionsViewModel model)
{
for (int i = 0; i < model.Sends.Count; i++)
{
Send send = new Send(new SendService(new Database().GetConnectionString()))
{
SendID = model.Sends[i].SendID,
Title = model.Sends[i].Title,
Subject = model.Sends[i].Subject,
SentDate = model.Sends[i].SentDate,
TimesViewed = model.Sends[i].TimesViewed,
Include = model.Sends[i].Include,
Exclude = model.Sends[i].Exclude
};
send.UpdateIncludeExclude();
}
return View(model);
}
Here is my GetConnectionString() method in the Database class that is being sent via my SendService constructor.
public string GetConnectionString()
{
return System.Configuration.ConfigurationManager.ConnectionStrings["DEVConnectionString"].ToString();
}
And lastly, my unit test:
[Test]
public void TestAssignmentSelections()
{
var obj = new AssignmentController();
var actResult = obj.Selections() as ViewResult;
NUnit.Framework.Assert.That(actResult.ViewName, Is.EqualTo("Selections"));
}
Now, my unit test fails, and I get why. My unit test project has no access to the web.config of the project I am testing where my connection string resides.
I've done some research, and apparently just adding a web.config to my unit test project and putting the connection string in there as well will make it work.. but that seems like a hack.
What's the best way to go about this? Is there another way to write my code to accommodate for this?
You want to make your controller unit testable ? Don't do this.
new SendService(
With this code,you are hardcoding your concrete service implementation & your data access code implementation. In your unit test, you should not be really accessing the data from your database. Instead you should be providing a mock data access implementation.
Here comes interfaces, you need to create an interface for your SendService.
public interface ISendService
{
void SomeMethod();
}
now your SendService will be a concrete implementation of this interface
public class SendService : ISendService
{
public void SomeMethod()
{
// Do something
}
}
Now update your controller to have a constructor where we will inject an implementation of ISendService.
public class YourController : Controller
{
private ISendService sendService;
public YourController(ISendService sendService)
{
this.sendService = sendService;
}
public ActionResult YourActionMethod()
{
// use this.sendService.SomeMethod();
}
}
And you may use some dependency injection frameworks to tell the MVC framework which implementation of the interface to use when the code runs. If you are using MVC6,It has an inbuilt dependency injection provider you can use. So go to your Startup class and in your ConfigureServices method, you can map an interface to a concrete implementation.
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
services.AddTransient<ISendService, SendService>();
}
}
If you are in a previous version of MVC, You may consider DI frameworks like Unity,Ninject etc. You can do the same approach for your Data access later / Service layers. ie: Create an interface for data access and inject that to your SendService.
public Interface IDataAccess
{
string GetName(int id);
}
and an implementation which uses your specific data access code/ORM
public class EFDataAccess : IDataAccess
{
public string GetName(int id)
{
// return a string from db using EF
}
}
So now your Service class will be
public class SendService : ISendService
{
private IDataAccess dataAccess;
public SendService(IDataAccess dataAccess)
{
this.dataAccess=dataAccess;
}
// to do : Implement methods of your ISendService interface.
// you may use this.dataAccess in those methods as needed.
}
In your unit tests, you can create a mock implementation of your interfaces which returns static data instead of accessing the database.
For example, If you are using Moq mocking framework, you can do this.
var m = new Mock<IDataAccess>();
var m.Setup(s=>s.GetName(It.IsAny<int>())).Returns("Test");
var s = new SendService(m);
var result= s.SomeMethod();
I have a Controller named "UserController" with method named "Invite". My controller has the following override method:
DBRepository _repository;
protected override void Initialize(System.Web.Routing.RequestContext requestContext)
{
base.Initialize(requestContext);
_repository = new DBRepository();
}
so, this method is called each time when UserController class is created.
My method "Invite" has the following lines:
var startTime = _repository.Get<AllowedTime>(p => p.TimeID == selectTimeStart.Value);
but when I try to call this method via Unit method:
[TestMethod()]
[UrlToTest("http://localhost:6001/")]
public void InviteTest()
{
UserController target = new UserController(); // TODO: Initialize to an appropriate value
int? selectTimeStart = 57;
int? selectTimeEnd = 61;
Nullable<int> selectAttachToMeeting = new Nullable<int>(); // TODO: Initialize to an appropriate value
int InvitedUserID = 9; // TODO: Initialize to an appropriate value
UserInviteModel model = new UserInviteModel();
model.Comment = "BLA_BLA_BLA";
ActionResult expected = null; // TODO: Initialize to an appropriate value
ActionResult actual;
actual = target.Invite(selectTimeStart, selectTimeEnd, selectAttachToMeeting, InvitedUserID, model);
Assert.AreEqual(expected, actual);
Assert.Inconclusive("Verify the correctness of this test method.");
}
I got an error "Reference is not set...". I understand why it happens (_repository is null because Initialize method is not called in my case, but how to do it correctly?
If you expect DBRepository to actually perform the Get from your backing data store during your test, you could change your _repository field to be a Lazy<DBRepository>, that gets initialized upon first use. (I'm assuming it's being newed up in the Initialize method rather than the constructor because it relies on the current request context?)
If you want this to be a true unit test, it shouldn't test the DBRepository class at all: you should be programming to an interface that you can mock up. Additionally, you need to make it so that your DBRepository comes from someplace where it can be provided by the test case. You could have it built by a factory or provided as a singleton, and the test case could set up the factory or singleton to provide a mocked object ahead of time. However, the best approach would be to use Dependency Injection, so you can provide a fake/mock IDBRepository when you construct the new UserController().
I am unit-testing my controller.
In one of my controller methods I am setting Session variables:
public void Index()
{ Session["foo"] = "bar";
return View();
}
How can I unit-test this? The problem is that the Session property is null when testing. Injecting is not possible because the Session property is readonly.
I don't want to use any third-party tool or mocking.
Simply dont use things like Session["foo"] in your controller methods. Best practice is keep action methods unaware of any context-like global objects. Everything your action method needs should be given to her in form of arguments. Note that built-in mechanism of model binding works exactly like that - you dont use Request.Form[], you let "somebody behind the scene" pass it to your action as argument.
Now for the session you can do the same - write you very simple ValueProvider which will know how to recognize arguments you want to fill from session, and you are done. In production your actions will work with session, in test you cant simply pass them any values you want as arguments.
For inspiration look at this http://www.prideparrot.com/blog/archive/2012/7/how_to_create_a_custom_session_value_provider
Injecting is not possible because the Session property is readonly.
This means you cannot use setter injection, but could you use constructor injection, ie add a constructor for your controller that is something like:
MyController(Session session)
{
m_session = session;
// then call your main constructor
}
Session getSession()
{
return m_session;
}
You can then use this separate constructor during testing.
I agree with #rouen. do not directly use Session["foo"]. But I think having ValueProvider ans might not be a practical solution, as we only store very few variables, and these values may be and most likely not ur full model.
So my approach is something similar to what Vic Smith suggests but a much more IOC (and Mock) friendly.
I would create a provider (i.e a service) to retrieve the session variables
public class SessionVariableProvider : ISessionVariableProvider
{
public object GetSessionValue(string key)
{
if (!HttpContext.Current.Session.IsNewSession
&& HttpContext.Current.Session[key] != null)
{
return HttpContext.Current.Session[key];
}
throw new ArgumentNullException(key);
}
public void SetSessionValue(string key, object value)
{
HttpContext.Current.Session[key] = value;
}
}
public interface ISessionVariableProvider
{
object GetSessionValue(string key);
void SetSessionValue(string key, object value);
}
Modify your Controller expect ISessionVariableProvider as a parameter.
public class TestController: Controller
{
protected readonly ISessionVariableProvider _sessionVariableProvider;
protected InowiaControllerBase(ISessionVariableProvider sessionVariableProvider)
{
Guard.ArgumentNotNull(sessionVariableProvider, "sessionVariableProvider");
this._sessionVariableProvider = sessionVariableProvider;
}
public ActionResult Index()
{
_sessionVariableProvider.SetSessionValue("foo", "bar");
var foo2 = (string)_sessionVariableProvider.GetSessionValue("foo2");
return View();
}
}
when testing create your own test implementation of ISessionVariableProvider and pass it to the controller.
[HttpPost]
public ActionResult Create(Car car)
{
_repository.CreateCar(car);
_repository.UpdateRegistrationDetails(car);
}
What I'm wanting to do is write unit test to ensure that Create calls CreateCar and UpdateRegistrationDetails. It doesn't matter about what happens in these methods but just that they get called. Could someone please tell me how to do this? Do I need to use a mocking framework for this? I have RhinoMocks installed to use. Do you use the Expect in RhinoMocks?
Again using Moq I think you need to mock the Repository instead (assuming names here of course)
var mock = new Mock<IRepository>();
var controller = new Controller(mock.Object); //assuming this is how you create it
var car = new Car();
controller.Create(car);
mock.Verify(x => x.CreateCar(car));
mock.Verify(x => x.UpdateRegistrationDetails(car));
No need for Setup or Expect as the mocked methods do not return anything
[EDIT]
Here is a Rhino.Mocks example
var mock = MockRepository.GenerateStub<IRepository>();
var controller = new Controller(mock); //assuming this is how you create it
var car = new Car();
controller.Create(car);
mock.AssertWasCalled(x => x.CreateCar(car));
mock.AssertWasCalled(x => x.UpdateRegistrationDetails(car));
The best answer is to use a mocking framework as others here have mentioned. The dirty way, but sometimes faster if you don't want to learn mocking frameworks (which you really should) is to create a test class and override virtual methods. In your case something like
public class RepoUnderTest : Repo
{
public bool UpdateRegistrationDetailsCalled = false;
public override void UpdateRegistrationDetails(Car car)
{
base.UpdateRegistrationDetails(car);
UpdateRegistrationDetailsCalled = true;
}
}
then you can test something similar to
[HttpPost]
public ActionResult Create(Car car)
{
// Arrange
var _repository = new RepoUnderTest();
// Act
_repository.CreateCar(car);
// Assert
Assert.IsTrue(_repository.UpdateRegistrationDetailsCalled);
}
Again a mocking framework is best. And I'd vote for those, but sometimes this is an easy introduction to testing for these things before you get heavier into mocking.
Regarding using of Expect() in RhinoMocks. I preffer to use stubs and 'Stub()' or AssertWasCalled() methods as much as possible. Expect() is used in cases when nothing else works.
I'm having difficulty testing controllers. Original my controller for testing looked something like this:
SomethingController CreateSomethingController()
{
var somethingData = FakeSomethingData.CreateFakeData();
var fakeRepository = FakeRepository.Create();
var controller = new SomethingController(fakeRepository);
return controller;
}
This works fine for the majority of testing until I got the Request.IsAjaxRequest() part of code. So then I had to mock up the HttpContext and HttpRequestBase. So my code then changed to look like:
public class FakeHttpContext : HttpContextBase
{
bool _isAjaxRequest;
public FakeHttpContext( bool isAjaxRequest = false )
{
_isAjaxRequest = isAjaxRequest;
}
public override HttpRequestBase Request
{
get
{
string ajaxRequestHeader = "";
if ( _isAjaxRequest )
ajaxRequestHeader = "XMLHttpRequest";
var request = new Mock<HttpRequestBase>();
request.SetupGet( x => x.Headers ).Returns( new WebHeaderCollection
{
{"X-Requested-With", ajaxRequestHeader}
} );
request.SetupGet( x => x["X-Requested-With"] ).Returns( ajaxRequestHeader );
return request.Object;
}
}
private IPrincipal _user;
public override IPrincipal User
{
get
{
if ( _user == null )
{
_user = new FakePrincipal();
}
return _user;
}
set
{
_user = value;
}
}
}
SomethingController CreateSomethingController()
{
var somethingData = FakeSomethingData.CreateFakeData();
var fakeRepository = FakeRepository.Create();
var controller = new SomethingController(fakeRepository);
ControllerContext controllerContext = new ControllerContext( new FakeHttpContext( isAjaxRequest ), new RouteData(), controller );
controller.ControllerContext = controllerContext;
return controller;
}
Now its got to that stage in my controller where I call Url.Route and Url is null. So it looks like I need to start mocking up routes for my controller.
I seem to be spending more time googling on how to fake/mock objects and then debugging to make sure my fakes are correct than actual writing the test code. Is there an easier way in to test a controller? I've looked at the TestControllerBuilder from MvcContrib which helps with some of the issues but doesn't seem to do everything. Is there anything else available that will do the job and will let me concentrate on writing the tests rather than writing mocks?
Thanks
You can use some of the libraries that give you out of the box some of these objects. For example RhinoMock, NMock ... etc. I personally use Moq - it's good enough and free. What i like most in Moq is the linq expressions.
Most mocking engine will do all this for you. I use RhinoMocks but there are a lot more available. Also Moles is very new and interesting mocking engine (this generally comes with Pex which is yet more ammo in your unit testing arsenal)
MvcContrib + RhinoMocks. Check out the TestControllerBuilder in the MvcContrib.TestHelper library. Here's the official write-up: http://mvccontrib.codeplex.com/wikipage?title=TestHelper#Examples.
Here's an example of mocking a controller out for testing a UrlHelper: ASP.NET MVC: Mock controller.Url.Action
Here's a short explanation of how to use the TestControllerBuilder: http://codebetter.com/blogs/kyle.baley/archive/2008/03/19/testcontrollerbuilder-in-mvccontrib.aspx
Instead of mocking stuff, you can pass IAjaxRequest to constructor. Or make it base constructor class property (and use property injection). Or you can make your constructor implement IAjaxRequest and then apply global action filter on base constructor class that will setup IAjaxRequest.
This will help to abstract many things, including HttpContext stuff. Just don't abstract IHttpContext, abstract IUserContext, ISessionStorage, IAuthentication, IRequestDetails...
Another way is to use model binder directly on methods where you need specific information. See this post for example. You can make binder that will give you IsAjaxRequest, then you just make action to accept this parameter. Works very well because information is provided exactly to the method that needs it, not to the whole controller.