ASP.NET - Unit тест MembershipProvider

Question

Я пытаюсь модульного тестирования MembershipProvider, однако я не могу понять, как и есть ли необходимость модульного тестирования этого ...

Мой бизнес слой:

public interface IAccountService 
{ 
    MembershipCreateStatus CreateUser(string userName, string password, string email); 
} 

public class AccountService : IAccountService 
{ 
    private readonly MembershipProvider provider; 

    public AccountService() : this(null) { } 
    public AccountService(MembershipProvider providera) 
    { 
     this.provider = providera ?? Membership.Provider; 
    } 

    public MembershipCreateStatus CreateUser(string userName, string password, string email) 
    { 
     if (String.IsNullOrEmpty(userName)) throw new ArgumentException("Value cannot be null or empty.", userName); 
     if (String.IsNullOrEmpty(password)) throw new ArgumentException("Value cannot be null or empty.", password); 
     if (String.IsNullOrEmpty(email)) throw new ArgumentException("Value cannot be null or empty.", email); 

     MembershipCreateStatus status; 
     provider.CreateUser(userName, password, email, null, null, true, null, out status); 

     return status; 
    } 
} 

Единственные примеры, которые я нашел до сих пор, требуют «MockMembershipProvider» с локальной настройкой базы данных ... кажется мне странным.

Заранее спасибо.

Answer 1

Наличие «MockMembershipProvider с локальной настройкой базы данных» является нечетным по нескольким причинам.

Обычно вы не хотите указывать код доступа к данным тестирования. Тестирование вашего устройства должно выполняться очень быстро и выполняться часто и, следовательно, не требует доступа к базе данных. Вот почему вы должны быть в состоянии высмеять ваш уровень доступа к данным. Сохраняющиеся данные были бы приемлемы для тестирования интеграции, но обычно не модульное тестирование.

Остальная часть этого ответа основана на предположении, что вы не хотите ударять DB в своем модульном тесте.

---

Независимо от того, хотите ли вы провести тестирование, поставщик членства будет зависеть от того, что там происходит.

1. Если поставщик членства написан на заказ и содержит бизнес-логику, он должен быть протестирован на единицу. Если это так, то вам необходимо создать объект DAO в пределах провайдера членства, чтобы поставщик членства мог выполнять модульные тесты без , попав в базу данных.

2. Если поставщик членства просто осуществляет доступ к базе данных (напрямую или с переадресацией вызовов на уровень доступа к данным), вы не должны его тестировать. Если вы используете поставщик членства в asp.net Microsoft, вы также не должны его тестировать.

   Вместо этого вы должны создать макет MembershipProvider для использования в классе AccountService. Вы вольете фиктивную с помощью инъекции конструкторы, это цель следующего шаблонного кода

   public AccountService() : this(null) { } 
   public AccountService(MembershipProvider providera) 
   { 
       this.provider = providera ?? Membership.Provider; 
   } 
   

   Этого кода облегчает внедрение конструктора альтернативных реализаций (который включает в себя издеваются). Пример того, что тест может выглядеть следующим образом:

   [Test] 
       public void ExampleTestWithAHandRolledMock() 
       { 
        //arrange 
        var mockMembershipProvider = new MockMembershipProvider();//no db access in this mock implementation 
        var accountService = new AccountService(mockMembershipProvider); 
        //act 
        accountService.CreateUser("foo", "bar", "baz"); 
        //assert 
        Assert.IsTrue(mockMembershipProvider.MockUserExists("foo","bar","baz");//added a method to mock to confirm user was added 
       }