Domanda

Bene.

Quindi immagino che sia giunto il momento di dedicarmi ai test unitari, dal momento che tutti ne hanno parlato abbastanza a lungo.Ho installato NUnit e ho seguito alcuni tutorial di tipo "introduzione ai test unitari".

Attualmente sto mettendo insieme un piccolo framework per aiutare con la ricostruzione di una delle nostre app Web, quindi ho creato un progetto VS2008 per il mio framework e voglio testarlo mentre procedo.

Come diavolo posso eseguire il test unitario dei WebControl?I metodi sono tutti protetti o privati ​​e, poiché si tratta di un framework, non c'è molto altro oltre ai WebControl.

Qualche indicazione?

Brucia

È stato utile?

Soluzione

È possibile realizzare architetture di tipo model-view-controller o model-view-presenter senza utilizzare un framework completo.Hai già scoperto che testare le unità dei componenti dell'interfaccia utente è difficile.Ci sono modi per aggirare questo problema, ma probabilmente non vorrai seguire quella strada.Di solito questo renderà i tuoi test molto difficili da mantenere, ulteriori incubi di manutenzione sono qualcosa di cui i programmatori possono fare a meno :-)

Prova a separare le funzionalità che desideri testare in una classe "controller" o "presentatore".Quindi prova quella classe.Per renderlo più testabile puoi nascondere la classe usercontrol (la vista) dietro un'interfaccia e fare in modo che il controller o il presentatore comunichino con la vista attraverso l'interfaccia.In questo modo puoi simulare la vista nei tuoi test.

So che sembra un sacco di lavoro e sembra una soluzione alternativa, ma se ti abitui è un'architettura davvero carina che rende molto più semplice modificare il comportamento dell'interfaccia utente.Puoi sempre iniziare a utilizzare un framework mvc "reale" quando ne hai davvero bisogno :-)

Altri suggerimenti

Ues the assembly:InternalsVisibleTo attributo e sarai in grado di accedere a quei membri privati.

Inseriscilo nel tuo progetto webcontrol AssemblyInfo.cs (Sotto Proprietà nodo)

[assembly:InternalsVisibleTo("YourTestProjectName")]

Hai trovato il più grande punto dolente di ASP.NET.Per quanto riguarda le classi private sigillate che ostacolano i test unitari.

Questo è il motivo principale per cui gli utenti TDD utilizzeranno un framework MVC (ASP.NET MVC, Castle MonoRail) poiché fornisce una chiara separazione dai modelli di visualizzazione e dalla logica del controller.I controller sono completamente testabili.

Potresti anche esaminare i componenti di test tramite il browser come li vedrebbe un utente utilizzando un framework di test come WebAii.L'ho visto funzionare ed è piuttosto interessante.Mi è stato anche detto che puoi collegarlo a build automatizzate, ma non l'ho ancora visto.

Spero che sia d'aiuto ...

Questo è ormai un vecchio articolo, ma stavo usando NUnitASP per scrivere test nunit per asp.net WebControls nel 2004.Questo articolo fornisce un esempio dettagliato di testare un controllo semplice utilizzando il concetto di creazione di una classe "Tester" corrispondente che incapsula i dettagli del controllo dai test.Il Tester può (dovrebbe) anche trovarsi nello stesso assembly del tuo controllo, quindi può condividere alcune cose tra loro (ad es.funzioni di utilità, costanti, ecc.).

Ho usato la tecnica (e altri usano varianti della tecnica) ancora oggi per testare controlli molto sofisticati.

Spero che sia utile.

Il framework MVC menzionato sopra è il modo migliore per testare ciò che fa il controllo.Tuttavia testare come funziona è leggermente diverso.

Questo è del tutto improvvisato, ma potresti fare in modo che il controllo utente esponga alcuni metodi e proprietà protetti per restituire informazioni di convalida e quindi far sì che un controllo utente di test le erediti.Quel controllo potrebbe popolare campi, premere pulsanti e cosa no.Un po' disordinato ma potrebbe funzionare.

Puoi anche dare un'occhiata a questo Igloo di rinoceronte struttura.È un framework MVC compromesso per WebForms.

Ivonnapuò testare WebControls in isolamento, all'interno del contesto ASP.NET Basta chiamare session.getControl ("path.ascx") e verificare che abbia tutte le proprietà necessarie.

Li provi in ​​questo modo:

[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
}

Ecco il mio stub:

internal class ConditionQueryBuilderStub : ConditionQueryBuilder // ConditionQueryBuilder is a WebControl
{
    internal void RenderAllContents(HtmlTextWriter writer)
    {
        RenderContents(writer);
    }
}
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top