2008-10-28 11 views

Antwort

1

Benötigt Ihr Code tatsächlich einen über ASP.NET angemeldeten Benutzer oder benötigt er lediglich ein CurrentPrincipal? Ich glaube nicht, dass Sie sich programmatisch bei Ihrer Site anmelden müssen. Sie können eine GenericPrincipal erstellen, die Eigenschaften festlegen, die Sie benötigen, und beispielsweise an Thread.CurrentPrincipal oder einen verspotteten HttpContext anhängen. Wenn Ihr Code RolePrincipal oder etwas benötigt, würde ich den Code so ändern, dass er weniger an die ASP.NET-Mitgliedschaft gekoppelt ist.

+0

Ich brauche den Anruf zu Membership.GetUser(), um den aktuell angemeldeten Benutzer zurückzukehren. – ddc0660

+2

Rufen Sie Membership.GetUser() nicht direkt in der getesteten Klasse auf. Versorgen Sie die Klasse mit einem IGetUser beim Erstellen, verwenden Sie sie anstelle von Membership.GetUser(), und führen Sie dann zum Testen eine Scheinimplementierung von IGetUser durch. –

0

Mit Ihrem Mitgliedschaftsanbieter können Sie einen Benutzer mit Membership.ValidateUser validieren. Dann können Sie den Authentifizierungscookie mit FormsAuthentication.SetAuthCookie festlegen. Solange Sie einen Cookie-Container haben, sollten Sie einen Benutzer anmelden können.

2

Ich habe es am bequemsten gefunden, eine Einwegklasse zu erstellen, die das Setzen und Zurücksetzen von Thread.CurrentPrincipal behandelt.

public class TemporaryPrincipal : IDisposable { 
     private readonly IPrincipal _cache; 

     public TemporaryPrincipal(IPrincipal tempPrincipal) { 
      _cache = Thread.CurrentPrincipal; 
      Thread.CurrentPrincipal = tempPrincipal; 
     } 

     public void Dispose() { 
      Thread.CurrentPrincipal = _cache; 
     } 
    } 

In der Testmethode wickeln Sie einfach Ihren Anruf mit einer using-Anweisung wie folgt aus:

using (new TemporaryPrincipal(new AnonymousUserPrincipal())) { 
    ClassUnderTest.MethodUnderTest(); 
} 
13
if(Membership.ValidateUser("user1",[email protected])) 
     { 
      FormsAuthentication.SetAuthCookie("user1",true); 
}