I have an asp .net core project, and practically in each action we use session, my question is how to test it if I don't have sessionRepository. Controller tests crush because session in controller is null. I try to Moq IHttpContextAcessor and it also doesn't work.
I try this:
HttpContext.Current = new HttpContext(new HttpRequest(null, "http://tempuri.org", null), new HttpResponse(null));
but HttpContext doesn't contain the definition for Current. (using Microsoft.AspNetCore.Http;)
Is there any way to moq or test controllers that use HttpContext and sessions?
You can use ControllerContext to set the context to be DefaultHttpContext which you can modify to your needs.
var ctx = new ControllerContext() { HttpContext = new DefaultHttpContext()};
var tested = new MyCtrl();
tested.ControllerContext = ctx;
The controller has an Controller context which you can set (i used the default one) :
Controller.ControllerContext = new ControllerContext
{
HttpContext = new DefaultHttpContext()
};
After time I think is bad idea to moq Session, better way is to create a IOC container, for example we create ISessionManager interface with methods which return stored in session objects:
public class SessionManager:ISessionManager{
public User GetUser(){
User usr= JsonConvert.DeserializeObject<User>(HttpContext.Session.GetString("USER"));
return usr;
}
***here we get data from session***
}
for UnitTest we just create a new class which implement ISessionManager and use it for test Controller's.
public class SessionManagerTest:ISessionManager{
public User GetUser(){
User usr=new User();
...initialize all fields
return usr;
}
******
}
Related
I am designing an n-tier application using Repository Layer/Service Layer/Presentation Layer using c#.net web api and Autofac DI container. Here is my dilemma. I am trying to unit test my web api controllers but my repositories have a property dependency on IPrincipal which I would like to property inject into my repository layer. I would like to create a MockUser(IPrincipal) and inject this object into my repository. Here is my current hierarchy, my controllers are constructor injected with the service object, my service object is constructor injected with my repository object. This part seems to work. But for some reason, every time I run the test my Principal property is null. Please review the code below and let me know what I am doing wrong:
Repository Base Class:
protected IPrincipal Principal
{
get { return _principal; }
}
Autofac Config Static Method
public class AutofacConfig
{
public static IContainer ConfigContainer()
{
var _builder = new ContainerBuilder();
UserPrincipal principal = MemberFactory.GetTestUser();
var _config = new HttpConfiguration();
_builder.RegisterControllers(typeof(BillingController).Assembly);
_builder.RegisterWebApiModelBinders(typeof(BillingController).Assembly);
_builder.RegisterApiControllers(typeof(BillingController).Assembly);
_builder.RegisterModelBinders(typeof(BillingController).Assembly);
_builder.RegisterModelBinderProvider();
_builder.RegisterModule(new AutofacWebTypesModule());
_builder.RegisterSource(new ViewRegistrationSource());
_builder.RegisterFilterProvider();
_builder.RegisterWebApiFilterProvider(_config);
//_builder.Register(x => principal).As<IPrincipal>().PropertiesAutowired();
_builder.RegisterType<BillingRepository>().As<IBillingRepository>().PropertiesAutowired();
_builder.RegisterType<UserPrincipal>().As<IPrincipal>().PropertiesAutowired();
_builder.RegisterType<GroupRepository>().As<IGroupRepository>().PropertiesAutowired();
_builder.RegisterType<BillingService>().As<IBillingService>().PropertiesAutowired();
_builder.RegisterType<UnitOfWork>().As<IUnitOfWork>();
_builder.Register(c => principal).As<IPrincipal>();
var _container = _builder.Build();
DependencyResolver.SetResolver(new AutofacDependencyResolver(_container));
// Create the depenedency resolver.
var resolver = new AutofacWebApiDependencyResolver(_container);
// Configure Web API with the dependency resolver.
_config.DependencyResolver = resolver;
return _container;
}
}
Test Controller (Get Method)
[TestClass]
public class BillingControllerTest
{
[TestMethod]
public async Task Get()
{
var _container = AutofacConfig.ConfigContainer();
var _controller = _container.Resolve<BillingController>();
var _bodyCompRecords = await _controller.GetMyOutstandingBills(1, 10);
Assert.IsNull(_bodyCompRecords);
Assert.IsNull(_bodyCompRecords.BillingList);
Assert.IsNull(_bodyCompRecords.CurrentPage);
Assert.IsTrue(_bodyCompRecords.BillingList.Count > 0);
}
}
Did you try to add a protected set for this property? I am not sure about autofac but maybe you should decorate this property with some attribute to autoFac knows that is a injectable property.
On the other hand, all threads in .Net applications has a single principal. You can get/set it on the Thread.CurrentPrincipal static property. You could try to set a custom Principal and make your property to result it.
In the setup of your Unittest, you could define it, for sample:
void Setup()
{
IPrincipal principal = new GenericPrincipal(new GenericIdentity("userName"), new string[] { "role1", "role2" });
Thread.CurrentPrincipal = principal;
}
In your repository, you could have a property to expose it,
protected IPrincipal Principal
{
get { return Thread.CurrentPrincipal; }
}
In a Web application (asp.net webforms/mvc/web api), you could use the HttpContext.Current.User static property, so, just call:
HttpContext.Current.User = principal;
as a good pratice, you could set both HttpContext.Current.User and Thread.CurrentPrincipal. Remember the web api is stateless, so, implement a http module to read arguments from http header and set the principal to your application. I am not sure if it is your case but this article shows how to do this.
http://www.asp.net/web-api/overview/security/basic-authentication
I'm working on an application which has two projects:
Core - houses the data access layer using repository pattern and domain-driven design
UI - using ASP.Net MVC. Currently, I am able to get the current logged in user's info(id, name, etc..) inside the UI controller via the User property like this:
using Microsoft.AspNet.Identity;
public class ExamController : Controller
{
IExaminationRepository _repository;
public ExamController()
{
_repository = RepositoryFactory.Get<IExaminationRepository>();
}
[HttpPost]
[Authorize(Roles = "Examiner")]
public ActionResult Create(ExamViewModel viewModel)
{
try
{
ExaminationDomain domain = Mapper.Map<ExamViewModel, ExaminationDomain>(viewModel);
//TODO: Move this to the repository
domain.AuthorId = User.Identity.GetUserId();
_repository.Add(domain);
return RedirectToAction("Index");
}
catch
{
return View();
}
}
}
I would like to move the line: domain.AuthorId = User.Identity.GetUserId(); to my repository concrete implementation like this:
using Microsoft.AspNet.Identity;
using System.Security.Principal;
internal class ExaminationRepository
{
public DBEntities context;
public IPrincipal User;
public ExaminationRepository(DBEntities context)
{
this.context = context;
//I'd like to instantiate User property here:
this.User = "not sure what to instantiate with";
}
public void Add(ExaminationDomain domain)
{
Examination newExam = Mapper.Map<ExaminationDomain, Examination>(domain);
newExam.AuthorId = User.Identity.GetUserId();
newExam.CreatedBy = User.Identity.Name;
newExam.CreatedDate = DateTime.Now;
context.Examinations.Add(newExam);
context.SaveChanges();
}
But I am not sure what to instantiate the User property to in the constructor. I've read some suggestions to use WindowsIdentity.GetCurrent().User instead of creating a user property but this doesn't contain the user id, only user name.
Any other suggestions on getting user info?
I'd really appreciate some help on this..
Thanks,
I would decouple your repository from the httpcontext with a custom manager. For example I have a interface called IAUthenticationManager
public interface IAUthenticationManager
{
string CurrentUserId();
bool HasCurrentUserRole(string roleName),
}
Easy to test and fully decoupled.
This won't work easily since the repository can be used in many different contexts, even such contexts where user is not set. If you create a concrete dependency in your constructor, your repository will no longer be an independent data provider.
For example, referencing
HttpContext.Current.User.Identity
directly would create a dependency to a web context and the repository would be unusable in non-web contexts.
The best you could do is just to let the repository client provide this:
public void Add(ExaminationDomain domain, IPrincipal principal)
{
Examination newExam = Mapper.Map<ExaminationDomain, Examination>(domain);
newExam.AuthorId = principal.Identity.GetUserId();
newExam.CreatedBy = principal.Identity.Name;
newExam.CreatedDate = DateTime.Now;
context.Examinations.Add(newExam);
context.SaveChanges();
}
or (which could be possible)
public ExaminationRepository(DBEntities context, IPrincipal user)
{
this.context = context;
this.user = user;
}
The latter case could still be correctly resolved by an IoC container if you tell the container how to resolve the dependency.
In a web context, you could set the container to resolve it to HttpContext.Current.User.
In a non-web context, you could set the container to resolve it to WindowsIdentity.GetCurrent().User.
use HttpContext class witch is a singleton class:
first add a using to Microsoft.AspNet.Identity;
and then you can do some thing like this:
HttpContext.Current.User.Identity.GetUserId();
since GetUserId is an extension method you have a reference to Microsoft.AspNet.Identity
but if you need to access user information in several places of you app I suggest to have a wrapper class with properties that you need and instantiate when user logs in then store it in session variable this way you have two benefits:
1- you don't need to query db to get username, email etc.. on each user info usage across the app.
2- you don't need assembly that your repository lives to aspnet identity.
You need to instantiate this.User with identity information of current thread:
this.User = System.Threading.Thread.CurrentPrincipal;
var currentIdentity = (System.Security.Claims.ClaimsIdentity)User.Identity;
var userId = currentIdentity.Claims
.Where(p => p.Type.EndsWith("nameidentifier")).Single().Value;
Note that the type of CurrentPrincipal.Identity is an IIdentity. You can cast it to System.Security.Claims.ClaimsIdentity, which contains a property named Claims. This property contains all your claims, including userid and 3rd party token (e.g. Facebook token).
To retrieve UserId, find a claims with Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"
I'm extending the ApplicationUser class by adding a new property (as shown in the tutorial
Create an ASP.NET MVC 5 App with Facebook and Google OAuth2 and OpenID Sign-on (C#))
public class ApplicationUser : IdentityUser
{
public DateTime BirthDate { get; set; }
}
Now I want to create a Unit Test to verify that my AccountController is correctly saving the BirthDate.
I've created an in-memory user store named TestUserStore
[TestMethod]
public void Register()
{
// Arrange
var userManager = new UserManager<ApplicationUser>(new TestUserStore<ApplicationUser>());
var controller = new AccountController(userManager);
// This will setup a fake HttpContext using Moq
controller.SetFakeControllerContext();
// Act
var result =
controller.Register(new RegisterViewModel
{
BirthDate = TestBirthDate,
UserName = TestUser,
Password = TestUserPassword,
ConfirmPassword = TestUserPassword
}).Result;
// Assert
Assert.IsNotNull(result);
var addedUser = userManager.FindByName(TestUser);
Assert.IsNotNull(addedUser);
Assert.AreEqual(TestBirthDate, addedUser.BirthDate);
}
The controller.Register method is boilerplate code generated by MVC5 but for reference purposes I'm including it here.
// POST: /Account/Register
[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<ActionResult> Register(RegisterViewModel model)
{
if (ModelState.IsValid)
{
var user = new ApplicationUser() { UserName = model.UserName, BirthDate = model.BirthDate };
var result = await UserManager.CreateAsync(user, model.Password);
if (result.Succeeded)
{
await SignInAsync(user, isPersistent: false);
return RedirectToAction("Index", "Home");
}
else
{
AddErrors(result);
}
}
// If we got this far, something failed, redisplay form
return View(model);
}
When I call Register, it calls SignInAsync which is where the trouble will occur.
private async Task SignInAsync(ApplicationUser user, bool isPersistent)
{
AuthenticationManager.SignOut(DefaultAuthenticationTypes.ExternalCookie);
var identity = await UserManager.CreateIdentityAsync(user, DefaultAuthenticationTypes.ApplicationCookie);
AuthenticationManager.SignIn(new AuthenticationProperties() { IsPersistent = isPersistent }, identity);
}
At the lowest layer, the boilerplate code includes this tidbit
private IAuthenticationManager AuthenticationManager
{
get
{
return HttpContext.GetOwinContext().Authentication;
}
}
This is where the root of the problm occurs. This call to GetOwinContext is an extension method which I cannot mock and I cannot replace with a stub (unless of course I change the boilerplate code).
When I run this test I get an exception
Test method MVCLabMigration.Tests.Controllers.AccountControllerTest.Register threw exception:
System.AggregateException: One or more errors occurred. ---> System.NullReferenceException: Object reference not set to an instance of an object.
at System.Web.HttpContextBaseExtensions.GetOwinEnvironment(HttpContextBase context)
at System.Web.HttpContextBaseExtensions.GetOwinContext(HttpContextBase context)
at MVCLabMigration.Controllers.AccountController.get_AuthenticationManager() in AccountController.cs: line 330
at MVCLabMigration.Controllers.AccountController.<SignInAsync>d__40.MoveNext() in AccountController.cs: line 336
In prior releases the ASP.NET MVC team worked very hard to make the code testable. It seems on the surface that now testing an AccountController is not going to be easy. I have some choices.
I can
Modify the boiler plate code so that it doesn't call an extension method and deal with this problem at that level
Setup the OWin pipeline for testing purposes
Avoid writing testing code that requires the AuthN / AuthZ infrastructure (not a reasonable option)
I'm not sure which road is better. Either one could solve this. My question boils down to which is the best strategy.
Note: Yes, I know that I don't need to test code that I didn't write. The UserManager infrastructure provided MVC5 is such a piece of infrastructure BUT if I want to write tests that verify my modifications to ApplicationUser or code that verifies behavior that depends upon user roles then I must test using UserManager.
I'm answering my own question so I can get a sense from the community if you think this is a good answer.
Step 1: Modify the generated AccountController to provide a property setter for the AuthenticationManager using a backing field.
// Add this private variable
private IAuthenticationManager _authnManager;
// Modified this from private to public and add the setter
public IAuthenticationManager AuthenticationManager
{
get
{
if (_authnManager == null)
_authnManager = HttpContext.GetOwinContext().Authentication;
return _authnManager;
}
set { _authnManager = value; }
}
Step 2:
Modify the unit test to add a mock for the Microsoft.OWin.IAuthenticationManager interface
[TestMethod]
public void Register()
{
// Arrange
var userManager = new UserManager<ApplicationUser>(new TestUserStore<ApplicationUser>());
var controller = new AccountController(userManager);
controller.SetFakeControllerContext();
// Modify the test to setup a mock IAuthenticationManager
var mockAuthenticationManager = new Mock<IAuthenticationManager>();
mockAuthenticationManager.Setup(am => am.SignOut());
mockAuthenticationManager.Setup(am => am.SignIn());
// Add it to the controller - this is why you have to make a public setter
controller.AuthenticationManager = mockAuthenticationManager.Object;
// Act
var result =
controller.Register(new RegisterViewModel
{
BirthDate = TestBirthDate,
UserName = TestUser,
Password = TestUserPassword,
ConfirmPassword = TestUserPassword
}).Result;
// Assert
Assert.IsNotNull(result);
var addedUser = userManager.FindByName(TestUser);
Assert.IsNotNull(addedUser);
Assert.AreEqual(TestBirthDate, addedUser.BirthDate);
}
Now the test passes.
Good idea? Bad idea?
My needs are similar, but I realized that I don't want a pure unit test of my AccountController. Rather I want to test it in an environment that is as close as possible to its natural habitat (integration test, if you want). So I don't want to mock the surrounding objects, but use the real ones, with as little of my own code as I can get away with.
The HttpContextBaseExtensions.GetOwinContext method also got in my way, so I was very happy with Blisco's hint.
Now the most important part of my solution looks like this:
/// <summary> Set up an account controller with just enough context to work through the tests. </summary>
/// <param name="userManager"> The user manager to be used </param>
/// <returns>A new account controller</returns>
private static AccountController SetupAccountController(ApplicationUserManager userManager)
{
AccountController controller = new AccountController(userManager);
Uri url = new Uri("https://localhost/Account/ForgotPassword"); // the real string appears to be irrelevant
RouteData routeData = new RouteData();
HttpRequest httpRequest = new HttpRequest("", url.AbsoluteUri, "");
HttpResponse httpResponse = new HttpResponse(null);
HttpContext httpContext = new HttpContext(httpRequest, httpResponse);
Dictionary<string, object> owinEnvironment = new Dictionary<string, object>()
{
{"owin.RequestBody", null}
};
httpContext.Items.Add("owin.Environment", owinEnvironment);
HttpContextWrapper contextWrapper = new HttpContextWrapper(httpContext);
ControllerContext controllerContext = new ControllerContext(contextWrapper, routeData, controller);
controller.ControllerContext = controllerContext;
controller.Url = new UrlHelper(new RequestContext(contextWrapper, routeData));
// We have not found out how to set up this UrlHelper so that we get a real callbackUrl in AccountController.ForgotPassword.
return controller;
}
I have not yet succeeded to get everything working (in particular, I could not get UrlHelper to produce a proper URL in the ForgotPassword method), but most of my needs are covered now.
I've used a solution similar to yours - mocking an IAuthenticationManager - but my login code is in a LoginManager class that takes the IAuthenticationManager via constructor injection.
public LoginHandler(HttpContextBase httpContext, IAuthenticationManager authManager)
{
_httpContext = httpContext;
_authManager = authManager;
}
I'm using Unity to register my dependencies:
public static void RegisterTypes(IUnityContainer container)
{
container.RegisterType<HttpContextBase>(
new InjectionFactory(_ => new HttpContextWrapper(HttpContext.Current)));
container.RegisterType<IOwinContext>(new InjectionFactory(c => c.Resolve<HttpContextBase>().GetOwinContext()));
container.RegisterType<IAuthenticationManager>(
new InjectionFactory(c => c.Resolve<IOwinContext>().Authentication));
container.RegisterType<ILoginHandler, LoginHandler>();
// Further registrations here...
}
However, I'd like to test my Unity registrations, and this has proved tricky without faking (a) HttpContext.Current (hard enough) and (b) GetOwinContext() - which, as you've found, is impossible to do directly.
I've found a solution in the form of Phil Haack's HttpSimulator and some manipulation of the HttpContext to create a basic Owin environment. So far I've found that setting a single dummy Owin variable is enough to make GetOwinContext() work, but YMMV.
public static class HttpSimulatorExtensions
{
public static void SimulateRequestAndOwinContext(this HttpSimulator simulator)
{
simulator.SimulateRequest();
Dictionary<string, object> owinEnvironment = new Dictionary<string, object>()
{
{"owin.RequestBody", null}
};
HttpContext.Current.Items.Add("owin.Environment", owinEnvironment);
}
}
[TestClass]
public class UnityConfigTests
{
[TestMethod]
public void RegisterTypes_RegistersAllDependenciesOfHomeController()
{
IUnityContainer container = UnityConfig.GetConfiguredContainer();
HomeController controller;
using (HttpSimulator simulator = new HttpSimulator())
{
simulator.SimulateRequestAndOwinContext();
controller = container.Resolve<HomeController>();
}
Assert.IsNotNull(controller);
}
}
HttpSimulator may be overkill if your SetFakeControllerContext() method does the job, but it looks like a useful tool for integration testing.
I have a project where I need to provide action tests. My approuch has been to ensure actions do not rely on anything they do not receive as parameters, maing use of ValueProviders and ModelBinders. As such I would pass in HTTPContextBase etc.
However, I now have an action which uses a static class that is a wrapper around HTTPContext to accesses Session and Identity. Thus it seems I have to mock out HTTPContext to test this action. Not too complicated, I guess, but it just feels wrong.
My gut feeling is that the static class should be redeveloped to be instantiated with HTTPSessionStateBase and IPrinicple and use them as internal stores. Then I could instantiate this wrapper in my action, from action parameters, making the action and the wrapper class much more testing friendly.
Would this be a recommended approuch or does anyone have any other ideas, were I would not have to change my static class to instance ?
I think that using Moq to mock a HttpContext is just the way you might want to try it out.
[TestMethod]
public void Test()
{
var context = new Mock<HttpContextBase>();
var request = new Mock<HttpRequestBase>();
context.Setup(c => c.Request).Returns(request.Object);
HomeController controller = new HomeController();
controller.ControllerContext = new ControllerContext( context , new RouteData(), controller );
....
...........
}
Updated:
In the case if you want to mock HttpSession(as gdoron mentioned in comment). It is not really complicated since you are MOCKING something doesn't means you have to build entire, real object and all of its properties.
Suppose that your controller will
Checks whether user is authenticated.
Gets identity name.
Gets a value from Session["key"].
manipulates cookie.
The code could be like that:
[TestMethod]
public void Test()
{
......
.........
var mockedControllerContext = new Mock<ControllerContext> ();
mockedControllerContext.SetupGet(p => p.HttpContext.Session["key"]).Returns("A value in session");
mockedControllerContext.SetupGet(p => p.HttpContext.Request.IsAuthenticated).Returns(true);
mockedControllerContext.SetupGet(p => p.HttpContext.User.Identity.Name).Returns("An identity name");
mockedControllerContext.SetupGet(p => p.HttpContext.Response.Cookies).Returns(new HttpCookieCollection ());
HomeController controller = new HomeController();
controller.ControllerContext = mockedControllerContext.Object;
.....
......
}
I strongly recommend using MvcContrib - testhelpers
Learn how to use from CodePlex
You can download it from nuget or directly from CodePlex
Good luck!
I'm currently developing an asp.net mvc 2 application which uses the default SqlMembershipProvider for authentication. I've implemented a controller method that reads the ProviderUserKey of the current user by calling Membership.GetUser().ProviderUserKey.
Now I'm trying to write some test methods for this controller.
To get rid of the dependancy on the static Membership class, I've created a thin wrapper and made my controller depend on the corresponding interface:
public interface IStaticMembershipService {
MembershipUser GetUser();
void UpdateUser(MembershipUser user);
}
So far everything works, but in order to unit-test the controller, I still need to mock the GetUser() method of this interface and return a MembershipUser object that contains a ProviderUserKey property. What is the easiest way to mock such an object?
I'm using moq as mocking framework.
It'd look something like this:
var membershipMock = new Mock<IStaticMembershipService>();
var userMock = new Mock<MembershipUser>();
userMock.Setup(u => u.ProviderUserKey).Returns(guid);
membershipMock.Setup(s => s.GetUser()).Returns(userMock.Object);
If the MembershipUser class doesn't lend itself to mocking (i.e. if ProviderUserKey isn't virtual), you'll want to create your own object to represent the values you're going to need from a MembershipUser object, and have your service return one of those instead.
There's also a slight possibility that a MembershipUser is a poco-like object, and you can create an instance like this:
var userMock = new MembershipUser {ProviderUserKey = guid};
I think you need to separate your implementation specifics from the interface the consumer really cares about. I'm not sure what your control needs the ProviderUserKey for, if it's casting it to a specific class, etc., but I would look at making your interface actually meet the controller's needs, not the other way around. Something like (without knowing more details):
public interface IMembershipDetailsService {
Guid UserKey { get; }
}
Once you do that level of abstraction, then mocking becomes much easier, because you could just do:
membershipService.Setup (svc => svc.UserKey).Returns (myGuid);
Just another thought, rather than trying to return a whole MembershipUser object you need to further stub.
Something similar to this:
var user = new MembershipUser();
var membershipService = new Mock<IStaticMembershipService>();
membershipService.Setup(p => p.GetUser()).Returns(user);
Could you do something like below if you need to Mock out the HttpContext stuff too.. below is using NUnit and Moq.
[SetUp]
private void Setup()
{
_mockHttpContext = new Mock<HttpContextBase>();
_mockStaticMembership = new Mock<IStaticMembershipService>();
_mockUser = new Mock<MembershipUser>();
_mockPrincipalUser = new Mock<IPrincipal>();
_mockHttpContext.Setup(http => http.User).Returns( _mockPrincipalUser.Object );
_mockPrincipalUser.Setup(principal => principal.Identity.Name).Returns("myname");
_mockUser.Setup(user => user.ProviderUserKey).Returns( Guid.NewGuid() );
_mockStaticMembership.Setup(membership => membership.GetUser(It.IsAny<string>())).Returns( _mockUser.Object );
}
[Test]
public void Some_Test_For_My_Controller()
{
var controller = new MyController( _mockStaticMembership.Object );
controller.ControllerContext = new ControllerContext(_mockHttpContext.Object, new RouteData(), controller);
//Test your action and verify
}