Frage

In Ordnung.

Ich denke, es ist an der Zeit, mich mit Unit-Tests zu befassen, da sich alle schon lange genug damit beschäftigt haben.Ich habe NUnit installiert und einige Tutorials vom Typ „Einführung in Unit-Tests“ durchgearbeitet.

Ich bin gerade dabei, ein kleines Framework zusammenzustellen, das bei der Neuerstellung einer unserer Web-Apps helfen soll. Deshalb habe ich ein VS2008-Projekt für mein Framework erstellt und möchte es im Laufe der Zeit einem Unit-Test unterziehen.

Wie um alles in der Welt gehe ich beim Unit-Testen der WebControls vor?Die Methoden sind alle geschützt oder privat, und da es sich um ein Framework handelt, gibt es nicht viel anderes als WebControls.

Irgendwelche Hinweise?

Verbrennungen

War es hilfreich?

Lösung

Sie können Architekturen vom Typ Model-View-Controller oder Model-View-Presenter erstellen, ohne ein vollständiges Framework zu verwenden.Sie haben bereits herausgefunden, dass Unit-Tests von UI-Komponenten schwierig sind.Es gibt Möglichkeiten, das zu umgehen, aber Sie möchten diesen Weg wahrscheinlich nicht gehen.Normalerweise wird die Wartung Ihrer Tests dadurch sehr schwierig, auf weitere Wartungsalpträume können Programmierer verzichten :-)

Versuchen Sie, die Funktionalität, die Sie testen möchten, in einer „Controller“- oder „Presenter“-Klasse herauszutrennen.Dann testen Sie diese Klasse.Um es besser testbar zu machen, können Sie die Usercontrol-Klasse (die Ansicht) hinter einer Schnittstelle verstecken und den Controller oder Präsentator über die Schnittstelle mit der Ansicht kommunizieren lassen.Auf diese Weise können Sie die Ansicht in Ihren Tests nachahmen.

Ich weiß, das klingt nach viel Arbeit und scheint ein Workaround zu sein, aber wenn man sich daran gewöhnt, ist es eine wirklich schöne Architektur, die es viel einfacher macht, das Verhalten der Benutzeroberfläche zu ändern.Sie können jederzeit mit der Verwendung eines „echten“ MVC-Frameworks beginnen, wenn Sie es wirklich benötigen :-)

Andere Tipps

Ues die assembly:InternalsVisibleTo Attribut und Sie können auf diese privaten Mitglieder zugreifen.

Fügen Sie es in Ihr Webcontrol-Projekt ein AssemblyInfo.cs (unter Eigenschaften Knoten)

[assembly:InternalsVisibleTo("YourTestProjectName")]

Sie haben den größten Schwachpunkt von ASP.NET gefunden.Soweit es versiegelte, private Klassen gibt, die Unit-Tests behindern.

Dies ist der Hauptgrund dafür, dass TDD-Benutzer ein MVC-Framework (ASP.NET MVC, Castle MonoRail) verwenden, da es eine klare Trennung von Ihren Ansichtsvorlagen und Ihrer Controller-Logik bietet.Die Controller sind vollständig testbar.

Sie können Testkomponenten auch über den Browser so betrachten, wie ein Benutzer sie mit einem Testframework sehen würde, z WebAii.Ich habe gesehen, dass es funktioniert und es ist ziemlich cool.Mir wurde auch gesagt, dass man es in automatisierte Builds integrieren kann, aber das habe ich bisher noch nicht gesehen.

Ich hoffe es hilft ...

Das ist mittlerweile ein alter Artikel, aber ich habe 2004 NUnitASP verwendet, um Nunit-Tests für asp.net WebControls zu schreiben.Dieser Artikel enthält ein detailliertes Beispiel für das Testen eines einfachen Steuerelements mithilfe des Konzepts der Erstellung einer entsprechenden „Tester“-Klasse, die die Details Ihres Steuerelements aus Ihren Tests kapselt.Der Tester kann (sollte) sich auch in derselben Baugruppe wie Ihre Steuerung befinden, sodass einige Dinge zwischen ihnen ausgetauscht werden können (z. B.Nutzenfunktionen, Konstanten usw.).

Ich habe die Technik (und andere verwenden Varianten der Technik) noch heute verwendet, um sehr anspruchsvolle Steuerungen zu testen.

Ich hoffe, das ist hilfreich.

Das oben erwähnte MVC-Framework ist der beste Weg, um zu testen, was das Steuerelement tut.Das Testen der Funktionsweise ist jedoch etwas anders.

Das ist völlig unrealistisch, aber Sie könnten dafür sorgen, dass das Benutzersteuerelement einige geschützte Methoden und Eigenschaften offenlegt, um Validierungsinformationen zurückzugeben, und diese dann von einem Testbenutzersteuerelement erben lassen.Dieses Steuerelement könnte Felder füllen, Schaltflächen drücken und was nicht.Etwas chaotisch, aber es könnte funktionieren.

Auch hier können Sie einen Blick darauf werfen Nashorn-Iglu Rahmen.Es handelt sich um ein kompromittiertes MVC-Framework für WebForms.

IvonnaKann Webcontrols isoliert testen, im ASP.NET -Kontext rufen Sie nur Session.getControl ("path.ascx") an und überprüfen Sie, ob es alle erforderlichen Eigenschaften enthält.

Sie testen sie so:

[Test]
public void ConditionQueryBuilderTest_RendersProperHtml()
{
    var sw = new StringWriter();
    var queryBuilder = new ConditionQueryBuilderStub
    {
        ID = "UnitTestbuilder",
        QueryBuilderURL = @"\SomeAspxPage\SomeWebMethod",
        ResetQueryBuilderURL = @"\SomeAspxPage\OnQueryBuilderReset",
        FilterValuesCollection = new Dictionary<int, string> { {15, "Some Condition"}}
    };
    queryBuilder.RenderAllContents(new HtmlTextWriter(sw));

    AppendLog(sw.ToString());

    Assert.AreEqual(ExpectedHtml, sw.ToString()); // ExpectedHTML is the raw expected HTML
}

Hier ist mein Stub:

internal class ConditionQueryBuilderStub : ConditionQueryBuilder // ConditionQueryBuilder is a WebControl
{
    internal void RenderAllContents(HtmlTextWriter writer)
    {
        RenderContents(writer);
    }
}
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top