Wie testen Sie Subsonic Lazy-Loaded Eigenschaften?

Question

Lassen Sie uns sagen, dass ich die folgende Funktion haben möchte ich Test:

public void CancelOrder(Order order) 
{ 
    order.Status = "Cancelled"; 

    _emailService.SendEmail(order.User.Email, "Your order has been cancelled!"); 
} 

Nun ist die Order-Klasse ein SubSonic Klasse erzeugt und die User-Eigenschaft auf es ist faul-geladen, was bedeutet, dass, wenn ich order.User nennen .Email es tatsächlich eine SQL-Anweisung ausführt, um den Benutzer abzurufen.

Wenn ich dies testen wollte, würde ich Probleme haben, weil ich nicht wirklich möchte, dass mein Komponententest meine Datenbank trifft.

Meine aktuelle Lösung ist die CancelOrder Funktion Refactoring wie folgt aussehen:

public void CancelOrder(Order order) 
{ 
    order.Status = "Cancelled"; 

    User user = _userRepository.GetByUserID(order.UserID); 

    _emailService.SendEmail(user.Email, "Your order has been cancelled!"); 
} 

Dann kann ich den _userRepository.GetUserByID Stub() aufrufen, einen fest codierten Benutzerobjekt zurückzukehren.

Ist dies der beste Weg, dies zu tun? Ich denke, Sie könnten argumentieren, dass die zweite Implementierung sauberer ist, da der gesamte Datenzugriff über das Repository statt in den Eigenschaften verborgen erfolgt.

Answer 1

Ihre eigene Bestell-alike-Schnittstelle definieren, die die nackten Knochen Funktionalität, die Sie benötigen und verwenden, die als Argument Typ für die CancelOrder Methode:

interface Order { 
    public void Status(...); // or property 
    public string UserEmail(): 
} 

Dann eine Delegierung Implementierung dieser Schnittstelle erstellen, zum Beispiel SubsonicOrder, der die Datenbank aufruft. Verwenden Sie in Ihren Tests eine Stub-Implementierung. Ich erkenne, dass Sie vielleicht ein umfangreicheres Modell für die Bestelloberfläche benötigen; Dies ist nur ein Beispiel.

Bei Bedarf das gleiche mit den E-Mail-Service-Sachen (vielleicht durch Abhängigkeitsinjektion durch Konstruktor oder Service Locator).

Answer 2

Warum möchten Sie nicht, dass Ihr Komponententest Ihre Datenbank trifft? Wenn Sie MBUnit zum Schreiben Ihres Testfalls verwenden, können Sie den Komponententest einfach mit dem RollBack-Attribut markieren und alle Änderungen an der Datenbank werden rückgängig gemacht.

Ich habe immer Schreibgerättestfälle bevorzugt, die auf die Business-Schicht abzielen, aber die Datenbank tatsächlich anpingen, so dass der Komponententest dem ähnelt, was die Anwendung selbst verwenden wird.