I am using Moq and xUnit to create unit tests. However, because of the way my action methods are set up, I'm having a hard time doing so. In my controller, I use
var user = await userManager.FindByNameAsync(User.Identity.Name);
to get the the signed in user information. I used this approach to avoid the number of parameters Is there a way to mock this in a unit test, or should the controller be set up differently?
The AppUser class extends IdentityUser for specific properties that are used within the controller.
For mocking above you can do something like following,
Mock<UserManager<User>> userManagerMock = new Mock<UserManager<User>>();
userManagerMock
.Setup(m => m.FindByNameAsync(It.IsAny<string>()))
.Returns(Task.FromResult(It.IsAny<User>()));
Please note I haven't compiled this code, but you should be able to get the idea.
Related
I'm struggling with Net Core Identity, more specifically the UserManager API. I have two databases with the same logic structure, one of them is for testing and homologation purposes. I looked around for a good while and managed to somehow make the segregated access work under the same application, creating a "homologation ambient". Since I still have to perform user and role-related management, authentication, and other tasks, it is in my interest to keep the same functions of the default UserManager, but looking at a different database. And now I'm stuck with this: the GeneratePasswordResetTokenAsync() method from UserManager fails, depending on how I set the StartUp.cs:
StartUp.cs
services.Configure<IdentityOptions>(opt =>
{
opt.User.RequireUniqueEmail = true;
opt.Password.RequiredLength = 8;
opt.Lockout.AllowedForNewUsers = false;
opt.SignIn.RequireConfirmedAccount = true;
opt.SignIn.RequireConfirmedEmail = true;
opt.Tokens.PasswordResetTokenProvider = "passwordReset";
opt.Tokens.EmailConfirmationTokenProvider = "emailConfirmation";
});
services.AddIdentity<User, IdentityRole>()
.AddEntityFrameworkStores<DNDriveContext>()
.AddTokenProvider<TwoFactorTokenProvider<User>>("passwordReset")
.AddTokenProvider<EmailConfirmationTokenProvider<User>>("emailConfirmation");
services.AddIdentityCore<UserHom>()
.AddRoles<IdentityRole>()
.AddClaimsPrincipalFactory<UserClaimsPrincipalFactory<UserHom, IdentityRole>>()
.AddEntityFrameworkStores<DNDriveHomContext>()
.AddTokenProvider<TwoFactorTokenProvider<UserHom>>("passwordReset")
.AddTokenProvider<EmailConfirmationTokenProvider<UserHom>>("emailConfirmation");
Through my research on the topic, I came across the AddIdentityCore<TUser>() method above, and it works fine in creating a second UserManager<TUser> that I can access in the controller via DI. The roles work fine too, and I can perform token validations segregated from the "production" environment, but the moment I try to call GeneratePasswordResetTokenAsync(), I get the following error:
No IUserTwoFactorTokenProvider named 'passwordReset' is
registered.
I tried passing the IdentityOptions to each Identity individually instead of calling services.Configure<IdentityOptions>, but it didn't make a difference. I assume this is an issue of assignment since only one of the UserManagers works at a time. With the above configuration, UserManager<UserHom> will successfully generate the reset password token, but the main UserManager<User> will throw the above-mentioned error. Commenting the two AddTokenProvider<> at the end of AddIdentityCore<UserHom> fixes the main UserManager, but now the homologation one fails.
I'm aware of the possibility of making a custom UserManager, but as I said in the beginning, I would like to keep all the default functions of UserManager, and I have no idea of how to start implementing one of my own. What exactly is the explanation for what is happening and how do I fix this?
I have the following code in my controller action method:
if (User.Identity.IsAuthenticated)
{
// ...
}
It seems to work fine. But when I run a unit test that calls this action, it fails because User is null?
Can anyone suggest the best way to deal with this? Do I have to restructure this code just for unit tests?
You probably need to set the User property as part of your setup. You would do this by mocking the HttpContextBase via ControllerContext used to create the controller so that it returns your mocked user. Set your mocked ControllerContext into the ControllerContext property, and it will find User provided you've configured the object graph correctly.
The User property of the Controller class is copied from the current HttpContext - you have to provide a context and set the User there appropriately for this to work in your unit tests.
User will be null if you run the code outside of the context of a web request. It sounds like you're running tests on your methods directly.
You have two options.
The quickest fix to your problem, but not necessarily the most sustainable fix, would be to simply call your running website from your unit test as a WebRequest.
The more sustainable fix would be to gather your uses of context-dependent server-side functionality (such as User) into a single class that you can mock/fake.
Edit
Can anyone suggest the best way to deal with this? Do I have to restructure this code just for unit tests?
The bottom line answer is "yes". More importantly, you probably want to, because it will make your system more flexible and/or maintainable in the long run.
Here is a piece of code from one of the controller inside my ASP.NET MVC 3 App :
_destinationdetailRepository.Add(new DestinationDetail {
DestinationID = destination.DestinationID,
CreatedOn = DateTime.Now,
CreatedBy = User.Identity.Name
});
What is important here is the CreatedBy property value which is User.Identity.Name. It works great and I use this on another parts of my app as well. But, I guess this is not a unit test firendly way of doing things.
So, what is the way of using Membership data inside the controller so that I will be happy when I am unit testing my app.
But, I guess this is not a unit test firendly way of doing things.
No, it's unit test friendly and it is correct code. The User property is an IPrincipal interface that can be mocked in an unit test.
I'm writing a unit test for FluentMigrator. I am testing a method that gets called n times in succession. What I'd like to do is grab the successive inputs and stow them in a SortedList, so that I can verify the methods were called in the right order, then pass those inputs to the actual method -- like a temporary redirect. But, after reading the docs etc, I can't get it to work.
Code in the test:
var listOfVersions = new SortedList<int, long>();
int i = 0;
var runnerMock = Mock.Get(_runner); // runner is a MigrationRunner
runnerMock.Setup(r => r.RollbackToVersion(2))
.Callback((long v) =>
{
listOfVersions.Add(i, v);
i++;
_runner.RollbackToVersion(v, true); });
_runner.RollbackToVersion(2);
The error:
System.ArgumentException : Object instance was not created by Moq.
Parameter name: mocked
I'm coming from Moles, where dipping into the behavior of an object and then redirecting it isn't unusual. Maybe it is in Moq?
No. Really mocking frameworks fall into 2 camps. The ones that can mock anything and the other than can only mock Interfaces, Abstract/Virtual methods.
This is because they use very much a different interception technology. Moq, RhinoMocks etc use Castle's Dynamic Proxy Generator under the hood which all it does create an instance that exposes the same public interface. It uses this to record interactions with that object so you can verify on it. Abstract and Virtual members can be mocked cause it can derive from that class and prevent calls to the base class.
However Moles and TypeMock Isloator play around with the IL directly. I know for TypeMock it actually weaves IL into the methods you are trying to mock so you can intercept and record interactions on it for testing (It also stops further processing of the methods also). I know that Moles creates another assembly and you refer to that in your test method but I imagine it does very similar things to TypeMock.
If you want to mock concrete non overrideable methods you will have to use that latter frameworks.
I'm working on a site and there are two projects in the solution a business logic project and the website project. I understand that I want to keep the entity context out of the web project and only use the business objects the framework creates but I can't figure out how to save a modified object this way.
Let's say my entity model created this class:
public class Person //Person entity
{
Int32 Id {get;set;}
String Name {get;set;}
Address Address {get;set;} //Address entity
}
And I created this class to get a specific person:
public static class PersonController
{
public static Person GetById(int id)
{
using (Entities context = new Entities())
{
return context.Persons.FirstOrDefault(x => x.Id == id);
}
}
}
This allows me to get a person without a context by calling PersonController.GetById(1); and I can change the persons properties after I get them but I can't figure out how to save the modified information back to the database. Ideally I would like to partial class Person and add a .Save() method which would handle creating a context adding the person to it and saving the changes. But when I tried this a while ago there were all kinds of issues with it still being attached to the old context and even if I detatch it and attatch it to a new context it gets attached as EntityState.Unchanged, if I remember right, so when I call context.SaveChages() after attaching it nothing actually gets updated.
I guess I have two questions:
1) Am I going about this in a good way/is there a better way? If I'm doing this in a really terrible way I would appreciate some psudo-code to point me in the right direction; a link to a post explaining how to go about this type of thing would work just as well.
2) Can someone provide some psudo-code for a save method? The save method would also need to handle if an address was attached or removed.
There are many ways to handle Entity Framework as a persistence layer.
For one, it looks like you're not using pure POCOs. That is, you let EF generate the classes for your (in the EDMX.designer.cs file).
Nothing wrong with that, but it does inhibit a clean separation of concerns (especially when it comes to unit testing).
Have you considering implementing the Repository pattern to encapsulate your EF logic? This would be a good way to isolate the logic from your UI.
In terms of Save - this is where it gets difficult. You're right, most people use partial classes. Generally, you would have a base class which exposes a virtual "Save" method, which the partial classes can then override.
I personally don't like this pattern - i believe POCOs should not care about persistence, or the underlying infrastructure. Therefore I like to use pure POCOs (no code gen), Repository pattern and Unit of Work.
The Unit of Work handles the context opening/saving/closing for you.
This is how (my) Unit of Work does the magic. Consider this some code in your "Web" project:
var uOw = new UnitOfWork(); // this is class i created, implementing the UOW pattern
var person = repository.Find(10); // find's a "Person" entity (pure POCO), with id 10.
person.Name = "Scott";
uOw.Commit();
Or adding a new Person:
var uOw = new UnitOfWork();
var newPerson = new Person { Name = "Bob" };
repository.Add(newPerson);
uOw.Commit();
How nice is that? :)
Line 1 creates a new sql context for you.
Line 2 uses that same context to retrieve a single "Person" object, which is a hand-coded POCO (not generated by EF).
Line 3 changes the name of the Person (pure POCO setter).
Line 4 Saves the changes to the data context, and closes the context.
Now, there is a LOT more to these patterns than that, so I suggest you read up on these patterns to see if it suits you.
My repository is also implemented with Generics, so I can re-use this interface for all business entity persistence.
Also take a look at some of the other questions I have asked on Stack Overflow - and you can see how I've implemented these patterns.
Not sure if this is the "answer" you're looking for, but thought I'd give you some alternative options.