2010-11-21 12 views
6

Estoy tratando de unidad de prueba de la MembershipProvider, sin embargo no puedo encontrar la manera o si hay alguna necesidad de la unidad de pruebas de la misma ...ASP.NET - Unidad MembershipProvider prueba

Mi capa de negocio:

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; 
    } 
} 

Los únicos ejemplos que he encontrado hasta ahora requieren un "MockMembershipProvider" con una configuración de base de datos local ... parece bastante extraño para mí.

Gracias de antemano.

+1

En lo que exactamente qué necesitas ayuda? ¿Desea obtener ideas para pruebas unitarias que pondrán a prueba a su Proveedor? – Wodzu

Respuesta

6

Tener un "MockMembershipProvider con una configuración de base de datos local" es extraño por algunas razones.

Normalmente no desea el código de acceso a datos de prueba de la unidad. Las pruebas de su unidad deben ejecutarse muy rápido, y ejecutarse con frecuencia, y por lo tanto no requieren acceso a la base de datos. Es por eso que debería poder burlarse de su nivel de acceso a datos. Los datos persistentes serían aceptables para las pruebas de integración, pero normalmente no son pruebas unitarias.

El resto de esta respuesta se basa en la suposición de que no desea presionar el DB en su prueba de unidad.


Si desea probar la unidad, el proveedor de membresía dependerá de lo que está sucediendo allí.

  1. Si el proveedor de membresía está escrito a medida y contiene lógica comercial, entonces debe ser probado en unidades. Si este es el caso, necesita crear un objeto DAO falso dentro del proveedor de membresía para que el proveedor de membresía pueda ejercerse mediante pruebas unitarias sin presionando la base de datos.

  2. Si el proveedor de membresía simplemente está llevando a cabo el acceso a la base de datos (ya sea directamente o con reenvío de llamadas al nivel de acceso a datos), no debe probarlo en una unidad. Si está utilizando el proveedor de membresía asp.net de Microsoft, tampoco debería probarlo.

    En su lugar, debe crear un simulacro MembershipProvider para usar dentro de la clase AccountService. Va a inyectar el uso de inyección de constructor mock, este es el propósito del siguiente código repetitivo

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

    Este código facilita la inyección de constructor de implementaciones alternativas (que incluye burla). Un ejemplo de lo que una prueba podría ser:

    [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 
        }