I'm trying to unit test a custom action result. I recently watched Jimmy Bogard's excellent MvcConf video ("put your controllers on a diet") http://www.viddler.com/explore/mvcconf/videos/1/ and have started to try and implement some custom action results. I've managed that without a problem, the ActionResult works fine at runtime but I'm having trouble trying to unit test them.
Unfortunately in the code download there are no unit tests for Jimmy's custom action methods... which make me wonder.
I realise that action methods just return instances of the ActionResult types and its the MVC framework that actually calls the ExecuteResult method, which of course is not available when running the unit test. So my unit test is now just creating an instance of my custom ActionResult and I then call ExecuteResult.
Unfortunatley in the ExecuteResult method of my custom ActionResult it is also calling the ExecuteResult method of a ViewResult that I passed it. At that point it blows up. How should I be mocking/stubbing these things to get my unit test working?
public class SendToAFriendActionResult : ActionResult
{
public const string INVALID_CAPTCHA = "You don't appear to have filled out the two words from the security image correctly to prove you're a human. Please try again.";
public const string INVALID_MODEL_STATE = "You don't appear to have filled out all the details correctly. Please try again.";
public const string CONTACT_FAIL = "Unfortunately we experiend a problem sending the link. Please try again later.";
public const string SEND_TO_A_FRIEND_FAIL_KEY = "ContactFail";
private RedirectResult _success;
private ViewResult _failure;
private readonly SendToAFriendModel _model;
private readonly bool _captchaValid;
private readonly MessageBuilderServiceBase _mbs;
public RedirectResult Success
{
get { return _success; }
set { _success = value; }
}
public ViewResult Failure
{
get { return _failure; }
set { _failure = value; }
}
public SendToAFriendActionResult(RedirectResult success, ViewResult failure, SendToAFriendModel model, bool captchaValid, MessageBuilderServiceBase mbs)
{
_success = success;
_failure = failure;
_model = model;
_captchaValid = captchaValid;
_mbs = mbs;
}
public override void ExecuteResult(ControllerContext context)
{
if (!_captchaValid)
{
Failure.TempData[SEND_TO_A_FRIEND_FAIL_KEY] = INVALID_CAPTCHA;
// On reaching this point I receive the error
// Object reference not set to an instance of an object
// as the MVC framework calls FindView
Failure.ExecuteResult(context);
return;
}
if (!context.Controller.ViewData.ModelState.IsValid)
{
Failure.TempData[SEND_TO_A_FRIEND_FAIL_KEY] = INVALID_MODEL_STATE;
Failure.ExecuteResult(context);
return;
}
_mbs.RecipientEmailAddress = _model.EmailRecipient;
_mbs.SendersName = _model.SendersName;
_mbs.Url = _model.URL;
var result = _mbs.sendMessage();
if (!result)
{
Failure.TempData[SEND_TO_A_FRIEND_FAIL_KEY] = CONTACT_FAIL;
Failure.ExecuteResult(context);
return;
}
Success.ExecuteResult(context);
}
}
Here's the start of my unit test ...
IMessageService _emailMessageSerivce;
IGalleryRepository _repository;
var stfModel = new SendToAFriendModel
{
SendersName = "Someone",
URL = "http://someurl.com",
EmailRecipient = "a-friend#somewherelse.com"
};
var failure = new ViewResult() {ViewName ="SendToFriend"};
const bool captchaValid = false;
var fakeControlllerContext = MockRepository.GenerateStub<ControllerContext>(null);
var stf = new SendToAFriendActionResult(null, failure, stfModel, captchaValid, null);
stf.ExecuteResult(fakeControlllerContext);
I've put comments in the SUT to show were the problem occurs.
I know I should be stubbing/mocking somehow but I just can't seem to resolve this.
From ASP.NET MVC 2 In Action (coauthored by Jimmy Bogard):
By taking that hard-to-test code out
of an action and putting it into the
Execute method of an action result,
you ensure that the actions become
significantly easier to unit-test.
That’s because when you unit-test an
action, you assert the type of action
result that the action returns and the
state of the action result. The
Execute method of the action result
isn’t executed as part of the unit
test.
Unit tests are designed to isolate behavior and concerns. You're mixing concerns by calling ExecuteResult from within your custom Action. Instead, I would have the SendToAFriendActionResult return the actual ActionResult (Failure or Success):
public ActionResult GetAction(..)
{
ActionResult result;
//logic here to determine which ActionResult to return
return result;
}
In your Controller:
public ViewResult SendToAFriend()
{
return SendToAFriendActionResult(null, failure, stfModel, captchaValid, null)
.GetAction();
}
This method will allow the MVC framework to do its job and isolates those concerns outside your custom ActionResult. Your test should assert that the correct type of Action, failure or success, is returned based on the parameters you set going in.
Related
I'm just learning how dependency injection and mocking work, but I'd like some feedback on how I'm setting up a couple of tests. I can get them to pass, but I'm not sure this is all I need.
This is an MVC application that makes Web API calls to return data. For this example I'm running queries in the Web APIs that populate dropdowns.
Please give me any and all suggestions about what I'm doing right or wrong here or anything I should be doing differently.
Setup file for Dependency Injection - Unity.WebAPI (NuGet Package)
UnityConfig.cs
public static class UnityConfig
{
public static void RegisterComponents()
{
var container = new UnityContainer();
// register all your components with the container here
// it is NOT necessary to register your controllers
// e.g. container.RegisterType<ITestService, TestService>();
container.RegisterType<IDropDownDataRepository, DropDownDataRepository>();
GlobalConfiguration.Configuration.DependencyResolver = new UnityDependencyResolver(container);
}
}
CONTROLLER
public class DropDownDataController : ApiController
{
private IDropDownDataRepository _dropDownDataRepository;
//Dependency Injection (I'm using Unity.WebAPI)
public DropDownDataController(IDropDownDataRepository dropDownDataRepository)
{
_dropDownDataRepository = dropDownDataRepository;
}
[HttpGet]
public HttpResponseMessage DateList()
{
try
{
return _dropDownDataRepository.DateList();
}
catch
{
throw new HttpResponseException(new HttpResponseMessage(HttpStatusCode.NotFound));
}
}
}
REPOSITORY
public class DropDownDataRepository : IDropDownDataRepository
{
//Is this fine in here, or should it be injected somehow too?
private MyDatabaseEntities db = new MyDatabaseEntities();
public HttpResponseMessage DateList()
{
var sourceQuery = (from p in db.MyProcedure()
select p).ToList();
string result = JsonConvert.SerializeObject(sourceQuery);
var response = new HttpResponseMessage();
response.Content = new StringContent(result, System.Text.Encoding.Unicode, "application/json");
return response;
}
}
INTERFACE
public interface IDropDownDataRepository
{
HttpResponseMessage DateList();
}
UNIT TESTS
/// <summary>
/// Tests the DateList method is run
/// I pieced this kind of test together from examples online
/// I'm assuming this is good for a simple test
/// </summary>
[TestMethod]
public void DateListTest1()
{
//Arrange
var mockRepository = new Mock<IDropDownDataRepository>();
mockRepository.Setup(x => x.DateList());
var controller = new DropDownDataController(mockRepository.Object);
//Act
controller.DateList();
//Assert
mockRepository.VerifyAll();
}
/// <summary>
/// Tests the DateList method returns correct status code.
/// This will run with success, but I'm not sure if that's just
/// because I'm telling it to return what I'm expecting.
/// I welcome suggestions for improvement.
/// </summary>
[TestMethod]
public void DateListTest2()
{
//Arrange
var mockRepository = new Mock<IDropDownDataRepository>();
mockRepository
.Setup(x => x.DateList())
//This will only succeed if I have the Returns property here,
//but isn't that just bypassing the actual "test" of whether or
//not this works?
.Returns(new HttpResponseMessage(HttpStatusCode.OK));
DropDownDataController controller = new DropDownDataController(mockRepository.Object);
controller.Request = new HttpRequestMessage();
controller.Configuration = new HttpConfiguration();
//Act
var response = controller.DateList();
//Assert
Assert.AreEqual(HttpStatusCode.OK, response.StatusCode);
}
UPDATE 1
One of my main questions here is what the .Returns property actually does. In my second unit test, I'm telling it to return OK, then check if it returns OK. I can't see how that's actually testing anything.
One of my main questions here is what the .Returns property actually
does. In my second unit test, I'm telling it to return OK, then check
if it returns OK. I can't see how that's actually testing anything.
The code:
mockRepository
.Setup(x => x.DateList())
//This will only succeed if I have the Returns property here,
//but isn't that just bypassing the actual "test" of whether or
//not this works?
.Returns(new HttpResponseMessage(HttpStatusCode.OK));
Says that when the mockRepository recieves a call to DateList() then it should return a new HttpResponseMessage(HttpStatusCode.OK).
So inside
[HttpGet]
public HttpResponseMessage DateList()
when the unit test reaches the line
return _dropDownDataRepository.DateList();
The mocked object fires and returns new HttpResponseMessage(HttpStatusCode.OK)
A better name for this test would be instead of DateListTest2 something like DateList_Returns_Status_Code_From_Repository as that is what you're arranging in the test.
To be honest controller.DateList() doesn't have much logic so that's about the only golden path test you could have.
I am trying to work out how to write a unit test that will test that a controllers authorization is working. IE a user that is not logged in can't access the page. Does anybody know how to go about this? I am having trouble finding examples.
something like this (Pseudo Code)
[TestMethod]
public void Get_Auth_Page()
{
be_a_user_thats_not_logged_in = true;
// Arrange
MyController controller = new MyController();
// Act
var result = controller.Index();
// Assert
if(result.httpstatus == 403)
Assert.True();
}
If you are simply decorating your action method with [Authorize], you can just have a test that asserts the existence of the attribute:
[TestMethod]
public void Index_action_requires_authentication()
{
// If Index is overloaded, you might need to filter by argument list
MethodInfo indexMethod = typeof(MyController).GetMethod("Index");
bool requiresAuthentication =
Attribute.IsDefined(indexMethod, typeof(AuthorizeAttribute));
Assert.IsTrue(requiresAuthentication);
}
Obviously you aren't testing the Authorize implementation here, but it does serve to both document and to protect against developers accidentally removing it.
If you are running custom code, then you are probably returning a HttpStatusCodeResult, so you can just check for that:
public void Index_action_requires_authentication()
{
ActionResult result = new MyController().Index();
HttpStatusCodeResult statusCodeResult = result as HttpStatusCodeResult;
Assert.IsNotNull(statusCodeResult);
Assert.AreEqual(403, statusCodeResult.StatusCode);
}
If you are manually writing to the HttpResponse (Response.StatusCode or Response.Headers), then you'll need to mock the HttpContextBase as others have described.
I'm trying to figure out the best way to build my unit tests for an MVC app. I created a simple model and interface, which is used by the controller constructors so that the testing framework (Nsubstitute) can pass a mocked version of the repository. This test passes, as expected.
My problem is now I want to take this a step further and test the file I/O operations in the "real" instantiation of IHomeRepository. This implementation should read a value from a file in the App_Data directory.
I've tried building a test without passing a mocked version of IHomeRepsotory in, however HttpContext.Current is null when I run my test.
Do I need to mock HttpContext? Am I even going about this in the right way?
//The model
public class VersionModel
{
public String BuildNumber { get; set; }
}
//Interface defining the repository
public interface IHomeRepository
{
VersionModel Version { get; }
}
//define the controller so the unit testing framework can pass in a mocked reposiotry. The default constructor creates a real repository
public class HomeController : Controller
{
public IHomeRepository HomeRepository;
public HomeController()
{
HomeRepository = new HomeRepoRepository();
}
public HomeController(IHomeRepository homeRepository)
{
HomeRepository = homeRepository;
}
.
.
.
}
class HomeRepoRepository : IHomeRepository
{
private VersionModel _version;
VersionModel IHomeRepository.Version
{
get
{
if (_version == null)
{
var absoluteFileLocation = HttpContext.Current.Server.MapPath("~/App_Data/repo.txt");
if (absoluteFileLocation != null)
{
_version = new VersionModel() //read the values from file (not shown here)
{
BuildNumber = "value from file",
};
}
else
{
throw new Exception("path is null");
}
}
return _version;
}
}
}
[Fact]
public void Version()
{
// Arrange
var repo = Substitute.For<IHomeRepository>(); //using Nsubstitute, but could be any mock framework
repo.Version.Returns(new VersionModel
{
BuildNumber = "1.2.3.4",
});
HomeController controller = new HomeController(repo); //pass in the mocked repository
// Act
ViewResult result = controller.Version() as ViewResult;
var m = (VersionModel)result.Model;
// Assert
Assert.True(!string.IsNullOrEmpty(m.Changeset));
}
I believe you want test the real instantiation of IHomeRepository, which connects to a real database. In that case you need an App.config file, which specify the connection string. This is not a Unit test and it would an Integration Test. With HttpContext being null, you still can fake the HttpContext, retrieve real data from the database. See also here.
I am writing an app that I have been deploying to appharbor. I am having trouble getting my project to build now because I have expanded my tests. I believe the issue is that I am using a db initializer to populate the database with test seed data. These tests pass on my local box but once I deploy the tests fail on appharbor. I suspect I need to mock data but I am not sure how to do this. As an example, here is a controller test that I have for one of my action methods.
Controller
// GET: /Lead/Url
// TODO: Add optional url parameters
public ActionResult Url(string pfirstname, string plastname, string phone, int leadsource)
{
var lead = new Lead();
//store
lead.parent_FirstName = pfirstname;
lead.parent_LastName = plastname;
lead.parent_Phone = phone;
lead.LeadSourceID = leadsource;
lead.AgentID = 1;
if (ModelState.IsValid)
{
leadRepository.InsertLead(lead);
leadRepository.Save();
ViewBag.Message = "Success";
}
return View(lead);
}
//
// POST: /Lead/URL
[HttpPost, ActionName("Url")]
public ActionResult Url(Lead lead)
{
return View();
}
Unit Test
[TestMethod]
public void LeadUrl()
{
//ARRANGE
ILeadRepository leadrepository = new LeadRepository(new LeadManagerContext());
Database.SetInitializer<LeadManagerContext>(new LeadManagerInitializer());
LeadController controller = new LeadController(leadrepository);
//ACT
ViewResult result = controller.Url("Brad", "woods","465-456-4965",1) as ViewResult;
var lead = (Lead)result.ViewData.Model;
//ASSERT
Assert.AreEqual("Success" ,result.ViewBag.Message);
/*check for valid data */
Assert.AreEqual("Brad", lead.parent_FirstName);
}
Could someone please explain what I need to do next in order to improve code like this and get it to run again on app harbor successfully?
Actually you haven't verified interactions between controller and it's dependencies (repository). And this is the most important part - controller should pass your Lead object to repository. And then call Save (consider also to Unit Of Work pattern).
Also you should test controller in isolation, only this way you could be sure, that failing controller's test is an issue of controller, not of LeadRepository or LeadManagerInitializer.
// Arrange
Lead expected = CreateBrad();
var repository = new Mock<ILeadRepository>();
LeadController controller = new LeadController(repository.Object);
// Act
ViewResult result = (ViewResult)controller.Url("Brad", "woods", "465-456", 1);
// Assert
Lead actual = (Lead)result.ViewData.Model;
// All fields should be equal, not only name
Assert.That(actual, Is.EqualTo(expected));
Assert.AreEqual("Success", result.ViewBag.Message);
// You need to be sure, that expected lead object passed to repository
repository.Verify(r => r.InsertLead(expected));
repository.Verify(r => r.Save());
BTW I'd moved expected Lead creation to separate method:
private Lead CreateBrad()
{
Lead lead = new Lead();
lead.parent_FirstName = "Brad";
lead.parent_LastName = "woods";
lead.parent_Phone = "465-456";
lead.LeadSourceID = 1;
lead.AgentID = 1;
return lead;
}
Also you should override Equals method for Lead instances comparison:
public class Lead
{
// your current code here
public override bool Equals(object obj)
{
Lead other = obj as Lead;
if (other == null)
return false;
return other.parent_FirstName == parent_FirstName &&
other.parent_LastName == parent_LastName &&
// compare other properties here
other.AgentID == AgentID;
}
// also override GetHashCode method
}
BTW Why you don't pass Lead object to your action method (via POST message)?
You have to stub your repository. The easiest way to do that is to use mocking framework (I prefer Moq), and stub each method.
Something like this (for Moq):
var repository = new Mock<ILeadReporisory>();
repository.Setup(r => r.InsertLead(It.IsAny<Lead>()));
//raise, rinse, repeat
LeadController controller = new LeadController(repository.Object);
I am trying to write a unit test for our log out method. Among other things it FormsAuthentication.SignOut(). However, it throws a System.NullReferenceException.
I've created a mock; HttpContext (using Moq), but it is obviously missing something.
My mock context contains:
A mocked HttpRequestBase on Request
A mocked HttpResponseBase on Response
With a HttpCookieCollection on Request.Cookies and another on Response.Cookies
A mocked IPrincipal on User
I am aware I could go the wrapper route and inject an empty FormsAuth wrapper object in it's place, but I would really like to avoid the 3 additional files just to fix one line of code. That and I am still curious for an answer
So my question is "What is needed in the HttpContext to allow FormsAuthentication.SignOut() to execute."
The NullReferenceException in this case is actually being thrown by the call:
current.Request.Browser["supportsEmptyStringInCookieValue"]
You can test this assertion by calling:
HttpContext.Current.Request.Browser.SupportsEmptyStringInCookieValue
...which will also return the NullReferenceException. Contrary to the accepted answer, if you attempt to call:
CookielessHelperClass.UseCookieless(current, false, CookieMode)
...from the immediate window, this will return without error.
You can fix the exception like this:
HttpContext.Current.Request.Browser = new HttpBrowserCapabilities() { Capabilities = new Dictionary<string, string> { { "supportsEmptyStringInCookieValue", "false" } } };
...and the FormsAuthentication.SignOut() call will now succeed.
You can always wrap FormsAuthentication.SignOut() into another method and stub / mock it.
Create IFormsAuthenticationWrap interface.
public interface IFormsAuthenticationWrap
{
void SignOut();
}
Create wrap class that implements IFormsAuthenticationWrap
public class FormsAuthenticationWrap : IFormsAuthenticationWrap
{
public void SignOut()
{
FormsAuthentication.SignOut();
}
}
Your calling class is going to look something like this:
public class LogOutClass
{
private readonly IFormsAuthenticationWrap _formsAuthentication;
public LogOutClass() : this (new FormsAuthenticationWrap())
{
}
public LogOutClass(IFormsAuthenticationWrap formsAuthentication)
{
_formsAuthentication = formsAuthentication;
}
public void LogOutMethod()
{
// Code before SignOut
_formsAuthentication.SignOut();
// Code after SignOut
}
}
Now let's get to our test. You can stub / mock with Moq but I'm going to show here how you can do it manually.
Create your stub / mock class:
public class FormsAuthenticationStub : IFormsAuthenticationWrap
{
public void SignOut()
{
}
}
And the last write the test:
[TestMethod]
public void TestLogOutMethod()
{
var logOutClass = new LogOutClass(new FormsAuthenticationStub());
logOutClass.LogOutMethod();
}
Here's the code for signout.
public static void SignOut()
{
Initialize();
HttpContext current = HttpContext.Current;
bool flag = current.CookielessHelper.DoesCookieValueExistInOriginal('F');
current.CookielessHelper.SetCookieValue('F', null);
if (!CookielessHelperClass.UseCookieless(current, false, CookieMode) || current.Request.Browser.Cookies)
{
string str = string.Empty;
if (current.Request.Browser["supportsEmptyStringInCookieValue"] == "false")
{
str = "NoCookie";
}
HttpCookie cookie = new HttpCookie(FormsCookieName, str);
cookie.HttpOnly = true;
cookie.Path = _FormsCookiePath;
cookie.Expires = new DateTime(0x7cf, 10, 12);
cookie.Secure = _RequireSSL;
if (_CookieDomain != null)
{
cookie.Domain = _CookieDomain;
}
current.Response.Cookies.RemoveCookie(FormsCookieName);
current.Response.Cookies.Add(cookie);
}
if (flag)
{
current.Response.Redirect(GetLoginPage(null), false);
}
}
Looks like you need a CookielessHelperClass instance. Too bad it's internal and sealed - there's no way to mock it unless you're using TypeMock. +1 for wrapper suggestions :)
The wrapper is the clean way to go.
You mentioned in a comment that "this is going to be quite a big application", that's another argument to use the wrapper not the opposite. In a big application you want to have clear dependencies, and you want tests to be done easily.
You are trading clean dependencies that can be easily injected over obscure dependencies to the internal workings of asp.net in your tests.
On a different note: Use Reflector. I honestly don't know the inner dependencies of this specific part of asp.net, but you can clear any doubts with reflector.
Don't mock HttpContext, use a real one in your tests. This way you don't have to mock all these Http* stuff. You can use Ivonna and test your method directly, without mocking all these dependencies and getting mysterious exceptions.