Testing Account/Logon Action

Question

Я тестирую действие Account/Loggon с помощью встроенного инструмента тестирования Visual Studio 2010 и библиотеки классов из этого article, чтобы создать контекст поддельного контроллера. Когда я запускаю тестовый метод, это строки кода:

FormsAuthentication.SetAuthCookie(username, false);  

бросает исключение: ссылка на объект не указывает на экземпляр объекта

Чтобы проверить действие loggon, я думаю, что я должен создать контроллер с контекстом поддельного контроллера, который имеет коллекцию файлов cookie. Вот мой код тестирования блок:

AccountController controller = new AccountController(); 
    var cookies = new HttpCookieCollection(); 

    controller.ControllerContext = new FakeControllerContext(controller, cookies); 

    ActionResult result = controller.RemoteLogOn(username, password); 

Answer 1

Я не уверен, если это право путь, но это то, что мы делаем, и это работает.

Вместо прямого использования FormsAuthentication.SetAuthCookie, переведите его в интерфейс, например IFormsAuthenticationService, и реализуйте как обычно.

Признайте, что в контроллерах MVC, где требуется, например:

public AccountController(IFormsAuthenticationService formsAuthenticationService) 
{ 
    _formsAuthenticationService = formsAuthenticationService; // should use DI here 
} 

public ActionResult LogOn(string username, string pw) 
{ 
    if (yourLogicWhichChecksPw) 
     _formsAuthenticationService.SetAuthCookie(username, false); 
    return RedirectToAction("Index"); 
} 

Затем в блок-теста, использовать что-то вроде Moq подделать из интерфейса.

var username = "blah"; 
var pw = "blah"; 
var fakesFormsAuth = new Mock<IFormsAuthenticationService>(); 
fakeFormsAuth.Verify(x => x.SetAuthCookie(username, false), Times.AtLeastOnce());     
var controller = new AccountController(fakedFormsAuth.Object); 
controller.LogOn(username, pw); 

причина для насмешливого это потому, что нет абсолютно никакой необходимости блока-тестирование подлинности с помощью форм. Это встроенная, хорошо протестированная и стабильная часть структуры ASP.NET. Вот почему мы издеваемся над тем, где мы не заботимся о базовой реализации, вместо этого мы проверяем только то, что выполнялись определенные условия (он был вызван, выбрано исключение, установлена ​​какая-то переменная и т. Д.).

Проверьте свой собственный код, а не механику .NET.

Что касается статьи Стивена Вальтера, то это больше подходит для подделки RequestContext, когда определенный код вашего тестирования ожидает данных в запросе. Такие, как User.Identity, Request.IsAuthenticated, переменные формы и т.д. Вот где вам нужно фальсифицировать контекст, например, следующий код:

public ActionResult Save(SomeModel) 
{ 
    var user = Request.User.Identity; // this will be null, unless you fake the context. 
}