tdd - unit - Membresía burlona

unit test webapi

Question

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

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 me burlo de la llamada Membership.GetUser () para poder escribir pruebas para este método? Alguna sugerencia o ejemplos? Gracias.

Answer 1

¿Podría insertar una instancia MembershipProvider en su proveedor de perfiles y, si no se inyecta, recurrir a 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, supongo que tendrá que usar algo como TypeMock .

Answer 2

Me estoy encontrando con este problema también

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

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

Por cierto, aquí es cómo resolví 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 resolvieron esto encapsulando (envolviendo) la funcionalidad de membresía en 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, puede ver cómo se burlan de los objetos FormsAuthentication y Membership:

 [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.");
}