Identity: Make SignInManager and UserManager more unit-testable

[ianhong]

I tried to write unit tests for MusicStore. Many of controllers in MusicStore use SignInManager and UserManager, but it wasn't easy to mock them. I think we could make SignInManager and UserManager more unit-testable. For example, providing the default constructor, or making them use interfaces.

Thanks,

[HaoK]

The idea is that you mock the store and use the managers directly in your tests. You shouldn't need to swap out the managers.

[ianhong]

@Haok I'm creating unit tests for MusicStore controllers, and do you have any samples to mock the store??

[HaoK]

Depending on your tests, you can just do something like use a in memory store for identity, you can lift this https://github.com/aspnet/Identity/tree/dev/test/Microsoft.AspNet.Identity.InMemory.Test, or you can mock line by line which is a bit painful: https://github.com/aspnet/Identity/blob/dev/test/Microsoft.AspNet.Identity.Test/SignInManagerTest.cs

[rustd]

Please reopen this issue if you think there is a bug that we should fix.

[hannmtz85]

``` c#
public class FakeUserManager : UserManager
{
public FakeUserManager()
: base(new Mock>().Object,
new Mock>().Object,
new Mock>().Object,
new IUserValidator[0],
new IPasswordValidator[0],
new Mock().Object,
new Mock().Object,
new Mock().Object,
new Mock>>().Object,
new Mock().Object)
{ }

    public override Task<User> FindByEmailAsync(string email)
    {
        return Task.FromResult(new User{Email = email});
    }

    public override Task<bool> IsEmailConfirmedAsync(User user)
    {
        return Task.FromResult(user.Email == "[email protected]");
    }

    public override Task<string> GeneratePasswordResetTokenAsync(User user)
    {
        return Task.FromResult("---------------");
    }
}

```

[jholovacs]

Isn't that a bit ridiculous to mock what should be a simple interface? There should be an IUserManager<TUser> that UserManager<TUser> implements, instead of going umpteen levels deep into mocking hell. Nobody is trying to test the functionality of the UserManager, we should definitely not be instantiating this class to run unit tests, and it's similarly silly to require a class like this to be injected as a dependency. This is a poor design decision.