2009-08-07 5 views
2

Ich lerne TDD und das MVP-Muster. Ich habe eine einfache WinForms App erstellt, die wie ein Ersatz für das TOAD SQL-Tool ist. Ich versuche, zurückzugehen und Tests für den Code zu schreiben, den ich bereits geschrieben habe (was ich weiß, ist nicht der richtige Prozess für TDD, aber bitte ertragen Sie mit mir).Moq mit WinForms MVP Muster - fehlgeschlagen Test

In meiner Testklasse für das Formular möchte ich die konkrete Presenter testen, aber die WinForm als der Presenter hat echte Logik in sich, die getestet werden sollte. Wenn ich jedoch die Ansicht mit Moq verspotte, sehe ich keine erwarteten Ergebnisse. Im folgenden Code testet die erste 2 PASS, aber die dritte FAILS auf der ersten Assert.

Wenn ich den Debugger NUnit und Lauf anhängen, die Environment Eigenschaft nicht auf Environments.Test gesetzt, wenn presenter.IsDangerousSQL genannt wird:

private Mock<IQueryForm> mockWindow; 
private QueryFormPresenter presenter; 

/// <summary> 
/// Runs ONCE prior to any tests running 
/// </summary> 
[TestFixtureSetUp] 
public void TestFixtureSetUp() 
{ 
    //We're interested in testing the QueryFormPresenter class here, but we 
    //don't really care about the QueryForm window (view) since there is hardly any code in it. 
    //Therefore, we create a mock of the QueryForm view, and pass it to the QueryFormPresenter to use. 
    mockWindow = new Mock<IQueryForm>(); 
    presenter = new QueryFormPresenter(mockWindow.Object); 
} 

[Test] 
public void User_Can_Execute_Selects_From_Any_Environment() 
{ 
    Assert.AreEqual(false, presenter.IsDangerousSQL("select 1")); 
} 

[Test] 
public void User_Cant_Execute_Schema_SQL_On_Any_Environment() 
{ 
    Assert.AreEqual(true, presenter.IsDangerousSQL("alter table")); 
    Assert.AreEqual(true, presenter.IsDangerousSQL("DrOp table")); 
} 

//Updates, Deletes and Selects are allowed in Test, but not in Production 
[Test] 
public void User_Can_Only_Execute_Updates_Or_Deletes_Against_Test() 
{ 
    //mockWindow.SetupSet(w => w.Environment = Environments.Test); 
    mockWindow.Object.Environment = Environments.Test; 
    Assert.AreEqual(false, presenter.IsDangerousSQL("update ")); 
    Assert.AreEqual(false, presenter.IsDangerousSQL("delete ")); 

    //mockWindow.SetupSet(w => w.Environment = Environments.Production); 
    //mockWindow.Object.Environment = Environments.Test; 
    Assert.AreEqual(true, presenter.IsDangerousSQL("update ")); 
    Assert.AreEqual(true, presenter.IsDangerousSQL("delete ")); 
} 

Ich schätze jede Einblicke jedermann bieten kann! Und sollte die -Methode tatsächlich in einer Model-Klasse sein, da sie Geschäftslogik darstellt und nicht direkt auf eine Benutzeraktion reagiert?

Danke !!

Andy

+0

Können Sie den auskommentierten Code erklären? Es sieht so aus, als ob du es benutzen solltest. –

+0

Wenn sich der Code auf die "Präsentation der Ansicht" bezieht, sollte er sich in der VM befinden - z. B. möchten Sie "bad sql" hervorheben. Wenn nicht (z. B. wird es auch von Nicht-Sicht-Clients benötigt), sollte es vielleicht tiefer in ein Modell oder eine Dienstklasse gehen. – Gishu

Antwort

1

Angenommen, Ihr Code unter Test wird die Umwelt Eigenschaft überprüfen Sie würden wollen SetupGet verwenden, anstatt SetupSet (dh die mock sagen, was, wenn seine Umgebung zurückzukehren Eigenschaft genannt wird)

mockWindow.SetupGet(s => s.Environment).Returns(Environments.Test); 

Das liegt daran, dass Sie die Eigenschaft nicht im Code festlegen, den Sie erhalten.

Alternativ, wenn Sie die Umgebung Eigenschaft als Standardeigenschaft behandeln möchte, das ist, was Sie tun, wenn Sie Anweisungen schreiben wie

mockWindow.Object.Environment = Environments.Test; 

können Sie

mockWindow.SetupProperty(qf => qf.Environment); 

persönlich verwende Ich bevorzuge den ersten Ansatz.

+0

Vielen Dank !! Der zweite Ansatz funktioniert jedoch nicht, wenn ich mockWindow.Object.Environment = Environments.Test; mit der mockWindow.SetupProperty (qf => qf.Environment) ;. Ich stimme jedoch zu, dass der erste Ansatz der richtige Weg ist. Vielen Dank!! – Andy