Comment se moquer de la classe d'abonnement dans ASP.NET MVC pour activer les tests

Question

Je crée un site ASP.NET MVC 3 qui permet aux utilisateurs de s'enregistrer. À cette fin, j'utilise la classe (statique) Membership intégrée; certains disent qu'il est gonflé mais cela fonctionne bien et assez facilement, donc là vous êtes.

Quoi qu'il en soit, j'ai commencé à écrire et classe AdminService qui traitera des fonctionnalités liées à des comptes d'utilisateurs, et supposons que la question qu'il n'a qu'une seule méthode:

public class AdminService : IAdminService 
{ 
    public void DeleteUser(string username) 
    { 
     Membership.DeleteUser(username); 
    } 
} 

Utilisation de la classe d'adhésion comme celui-ci mal dans 2 façons: il ne peut pas être injecté via IoC et je trouve qu'il est de plus en plus difficile d'écrire des spécifications (test) pour IAdminService parce que je ne peux pas mocker la classe d'adhésion.

Existe-t-il un moyen de rendre la classe d'adhésion ASP.NET conviviale aux tests et à l'injection de dépendances sans rouler la mienne?

En ce qui concerne la fonctionnalité, la classe d'adhésion fonctionne bien et, plus important encore, il fonctionne maintenant, donc je suis vraiment réticent à commencer à écrire mon propre MembershipProvider car il ne me ralentir.

Answer 1

Si vous créez un projet ASP.NET MVC 3 non vide, il y aura le fichier AccountModels.cs dans votre dossier Modèles. Il contient un exemple de gestion de l'appartenance pour permettre le test unitaire:

public interface IMembershipService 
{ 
    int MinPasswordLength { get; } 

    bool ValidateUser(string userName, string password); 
    MembershipCreateStatus CreateUser(string userName, string password, string email); 
    bool ChangePassword(string userName, string oldPassword, string newPassword); 
} 

Answer 2

Avait cette même situation lorsque je construisais un site MVC, et a fini par rouler mon propre fournisseur (testable). Cela étant dit, une option serait de simplement lever l'implémentation de l'échantillon de here - vous pourriez (en théorie) juste construire un FakeProvider, et coder en dur les différentes méthodes de retour par rapport à une base de données SQL.

Le nombre total de méthodes dans l'un d'entre eux est assez léger, et ce ne serait pas une mauvaise chose à avoir pour quand vous voulez les truquer.