Il mio attuale progetto basato su Asp .net fa un uso considerevole dei gestori di HTTP per elaborare varie richieste? Quindi, c'è un modo in cui posso testare la funzionalità di ciascuno dei gestori usando i casi di test unitario? Stiamo utilizzando il framework Nunit e Moq per facilitare il test delle unità.Unità che controlla i gestori HTTP?
Sicuro, anche se non mi sono fatto "con rabbia".
Utilizzare System.Net.WebClient per effettuare chiamate HTTP verso i gestori e valutare cosa ritorna, che consentirà di testare l'interfaccia pubblica del gestore.
In questo esempio ho codificato il mio target e sto utilizzando un metodo sul WebClient che restituirà una stringa.
Il WebClient consente inoltre di accedere a ResponseHeaders, Encoding e altre utili risorse "webby"; puoi anche caricare informazioni.
using System.Net;
namespace UnitTestHttpHandler
{
public class TestHarness
{
public static string GetString()
{
WebClient myWebClient = new WebClient();
return myWebClient.DownloadString("http://localhost/Morphfolia.Web/ContentList.ashx");
}
}
}
è quindi possibile utilizzare il TestHarness per chiamare il bersaglio HttpHandler e verificare i risultati nei test (o usare un approccio migliore per il test se si conosce uno - io non sono un guru di test unit).
[TestMethod]
public void TestMethod1()
{
string x = UnitTestHttpHandler.TestHarness.GetString();
Assert.IsTrue(x.Length > 5);
}
Ecco un articolo che spiega chiaramente il test dell'unità per il gestore HTTP.
http://jgvimalan.wordpress.com/2011/08/30/unit-test-for-http-handler/
Si può fare test di integrazione del gestore utilizzando i metodi di cui le altre risposte, fare Unit Testing è necessario creare alcune interfacce ed estrarre le funzionalità di base fuori del gestore, così come crea alcuni oggetti finti.
Non sarà in grado di unit test tutte le parti di esso perché si basa su risorse esterne (quelle sarete prendendo in giro) - ma va bene, questo è per questo che abbiamo test di integrazione.
Credo che queste voci di blog da un po 'indietro sono rilevanti:
http://www.kongsli.net/nblog/2009/05/03/aspnet-35-improving-testability-with-systemwebabstractions/
vedi esempio # 2 nel primo post per un esempio su come unit test un HttpHandler.
Se si desidera testare la comunicazione tra i gestori e l'interfaccia utente Web, allora sì, il test di integrazione è la soluzione giusta. Al fine di testare la tua logica, non potresti invece separare la tua business logic in altre classi (io userei un assembly separato per il livello aziendale) e mock/unit testare queste classi al di fuori del tuo livello di presentazione?
Una volta che un livello aziendale strutturato (e testato unitamente) è stato separato dal livello di presentazione, i gestori possono semplicemente istanziare i calcestruzzi e invocare i metodi forniti. Una volta eseguita questa operazione, è possibile passare ai test di integrazione poiché la logica aziendale sarà stata sottoposta a test dell'unità.
Se non cura di test di unità e volete qualcosa di veloce e sporco è possibile utilizzare Fiddler
se si desidera un approccio (Unit testing) più integrato è possibile utilizzare il WebRequest e WebResponse.
Ma abbiamo bisogno di instradare (usando i file di configurazione) la richiesta al gestore corretto e anche il server deve essere in esecuzione, giusto? Quindi, come simularlo? –
Sì, un server web deve essere in esecuzione. Per quanto riguarda la configurazione, non posso parlare per esperienza, ma supponevo che sarebbe stato fatto in modo simile a specificare altre impostazioni via config quando test di unità (?). Scusa, non posso offrire molto di più. –
Questo funziona davvero bene, l'unico problema è che non è possibile eseguire il debug attraverso il gestore di destinazione, naturalmente. – Brent