Membresía burlona

Question

Estoy escribiendo un proveedor de perfil personalizado, pero todavía tengo la intención de utilizar el AspNetSqlMembershipProvider predeterminado como mi proveedor de membresía. Mi método GetAllProfiles() en el profesional de perfil es el siguiente:

1 public override ProfileInfoCollection GetAllProfiles(ProfileAuthenticationOption authenticationOption, int pageIndex, int pageSize, out int totalRecords) 
2 { 
3  // Get the profiles 
4  IQueryable<Profile> profiles = _profileRepository.GetAllProfiles(); 
5  
6  // Convert to a ProfileInfoCollection 
7  ProfileInfoCollection profileInfoCollection = new ProfileInfoCollection(); 
8  foreach (Profile profile in profiles) 
9  { 
10   MembershipUser user = Membership.GetUser(profile.UserId); 
11 
12   string username = user.UserName; 
13   bool isAnonymous = false; 
14   DateTime lastActivity = user.LastActivityDate; 
15   DateTime lastUpdated = profile.LastUpdated; 
16 
17   ProfileInfo profileInfo = new ProfileInfo(username, isAnonymous, lastActivity, lastUpdated, 1); 
18 
19   profileInfoCollection.Add(profileInfo); 
20  } 
21 
22  // Set the total number of records. 
23  totalRecords = profiles.ToList().Count; 
24 
25  return profileInfoCollection; 
26 } 

¿Cómo se burlan de la llamada Membership.GetUser() para que yo pueda escribir pruebas de este método? Alguna sugerencia o ejemplos? Gracias.

Answer 1

¿Podría inyectar una instancia de MembershipProvider en su proveedor de perfiles y, si no se inyectó ninguno, volver a utilizar Membership.Provider?

public MembershipProvider MembershipProvider 
{ 
    get { return _membershipProvider ?? Membership.Provider; } 
    set { _membershipProvider = value; } 
} 

Su proveedor de perfiles interactuará con el proveedor de membresía a través del valor devuelto por esta propiedad. En su prueba, usted inyectaría la instancia falsa/simulada MembershipProvider.

Si, por el contrario, quiere burlarse de los métodos estáticos de membresía, tendrá que usar algo como TypeMock, supongo.

Answer 2

estoy corriendo en este problema, así

el problema radica en el hecho de que el método GetUser() sin parámetros se implementa como un método estático de la clase.

Considerando que el Membership.Provider (cuando se burla) no contiene un método GetUser() sin parámetros.

Por cierto aquí es cómo solucioné este problema. Encapsulé la llamada estática en mi propia clase que implementa una interfaz para que pueda ser burlada.

public interface IStaticMembershipService 
{ 
    MembershipUser GetUser(); 

    void UpdateUser(MembershipUser user); 
} 

public class StaticMembershipService : IStaticMembershipService 
{ 
    public System.Web.Security.MembershipUser GetUser() 
    { 
     return Membership.GetUser(); 
    } 

    public void UpdateUser(MembershipUser user) 
    { 
     Membership.UpdateUser(user); 
    }  
} 

Answer 3

En ASP.NET MVC se resolvieron este encapsulando (envoltura) la funcionalidad de la pertenencia a un MebershipService. Lo cual (por ejemplo: a través de la inyección) puede simular fácilmente en sus pruebas.

Un ejemplo de servicios de burla ... http://www.asp.net/learn/mvc/tutorial-30-cs.aspx Aunque no usan inyección.

Un buen ejemplo es en realidad el proyecto de prueba generado cuando se crea una aplicación ASP.NET. En el siguiente código se puede ver cómo se burlan Los FormsAuthentication y la pertenencia objetos:

[TestMethod] 
    public void ConstructorSetsProperties() 
    { 
     // Arrange 
     IFormsAuthentication formsAuth = new MockFormsAuthenticationService(); 
     IMembershipService membershipService = new AccountMembershipService(); 

     // Act 
     AccountController controller = new AccountController(formsAuth, membershipService); 

     // Assert 
     Assert.AreEqual(formsAuth, controller.FormsAuth, "FormsAuth property did not match."); 
     Assert.AreEqual(membershipService, controller.MembershipService, "MembershipService property did not match."); 
    }