Come posso testare un sito di moduli Web?

Sì, puoi. Devi solo fare attenzione a separare bene le tue preoccupazioni. In breve, devi rimuovere tutta la tua logica dal code-behind e inserirla in altre classi.

Ci sono due modi comuni per farlo.

Il modo semplice è di ripensare tutti i gestori di eventi in termini di "Quali informazioni mi dà il sistema? Quali informazioni devo compilare nella pagina?" e quindi fornire una classe di servizio che esegue tale conversione.

In questo caso, il livello di servizio dovrebbe conoscere molto poco la natura del livello di presentazione. Bisogna ancora prendere i dati restituiti dal servizio e compilare i componenti corretti del WebForm nel code-behind e questo non viene verificato (almeno per i test unitari, è comunque possibile utilizzare i test di integrazione). Ma raramente il codice va storto, è molto più probabile che fallisca nella logica.

Un modo più complicato, ma più efficace, è utilizzare il modello Modeler Presenter . Quando l'abbiamo provato, abbiamo scoperto che i Presenter si sono rapidamente integrati al framework e, più sviluppavamo MVP, più chiaro era che MVP voleva davvero essere MVC ma non poteva esserlo.

Detto questo, altri lo hanno fatto con successo - esiste anche un framework webformsmvp disponibile per rimuovere il sollevamento pesante - quindi il tuo il chilometraggio può variare.

Ovviamente, un'intera pagina di moduli Web non è un'unità e pertanto non può essere sottoposta a test dell'unità. Tuttavia, ci sono alcune cose che puoi fare per i test automatici:

• unit test singoli componenti della pagina (qualsiasi metodo che esegue la logica effettiva)
• componenti test unitari utilizzati dalla pagina (controlli personalizzati, logica aziendale sottostante, ecc.)
• test delle funzionalità automatizzate (tramite il controllo remoto di un browser o l'invio di richieste HTTP tramite qualcosa come cURL)
• test di penetrazione automatizzata (ci sono strumenti che cercheranno di trovare i possibili punti di iniezione e faranno automaticamente attacchi di iniezione innocui ma rilevabili sulla tua pagina)
• carica test
• verifica il layout rispetto a un elenco di punti elenco di usabilità e in stile casa (anche se questo è molto difficile da automatizzare, di solito è più semplice farlo manualmente ogni tanto)

Mi dispiace per la mancanza della parte "unità" della domanda ...

SeleniumHQ è tuo amico per i test dal front end. Non è un test unitario, più come un test della scatola nera. Hai ancora bisogno di pensare a casi di test validi ...

Parlando dall'esperienza: solo se è fatto bene. Con "giusto" intendo il code-behind minimale e qualcosa come il Model-View-Presenter sopra menzionato per rendere il Web Form "stupido". Questo di solito si rivela molto difficile con le applicazioni brownfield perché non sono state progettate con questo in mente ed è uno sforzo quasi erculeo di rifattorizzare / riscrivere le pagine per usarlo.

Watin

Trovo che i web test delle unità siano estremamente utili, anche se è solo per dare un'idea generale di un bug di regressione o per nuovi progetti.

Per quanto riguarda lo stato, crei i tuoi test unitari come faresti con i test non dell'interfaccia utente: cancellano il database all'inizio del test e ricostruiscono il database per non contenere altro che lo stato iniziale. Ogni unità di test quindi incapsula una singola pagina, o di solito un'attività distinta su una pagina.

Il link è un altro strumento di test web ma per C # /. NET. Scrivi i test come test unitari:

[Test] 
public void SearchForWatiNOnGoogle()
{
  using (var browser = new IE("http://www.google.com"))
  {
    browser.TextField(Find.ByName("q")).TypeText("WatiN");
    browser.Button(Find.ByName("btnG")).Click();

    Assert.IsTrue(browser.ContainsText("WatiN"));
  }
}

Attualmente è basato su IE, ma ha qualche supporto sperimentale per Firefox e Chrome. Puoi praticamente automatizzare tutto ciò che vorresti fare nei test manuali, compresa l'interazione Javascript.

Non puoi davvero testare un sito web, semplicemente perché le richieste web si verificano su un filo (o attraverso uno stack TCP). Pertanto, i test non si adattano alla definizione di "unit test", sarebbero, probabilmente, test end-to-end.

Per questo tipo di test, è possibile utilizzare una suite come Selenium che esegue un browser Web dietro le quinte. Un avvertimento: solitamente questo tipo di test è molto difficile e imprevedibile, in quanto vi sono molte parti mobili!

Ancora più interessante, mi preoccupa un po 'il motivo per cui hai bisogno di testare i moduli web. Non stai mettendo troppa logica nel codice, e hai una logica aziendale anemica per caso?

Jasmine

Negli ultimi 5 anni Jasmine è emerso come uno strumento chiave per i test di unità front-end. È spesso incorporato nei test di build automatici con Node e npm

Per link :

Jasmine è un framework di test open source per JavaScript. [2] Ha l'obiettivo di funzionare su qualsiasi piattaforma abilitata a JavaScript, di non intromettersi nell'applicazione o nell'IDE e di avere una sintassi di facile lettura. È strongmente influenzato da altri framework di test unitari, come ScrewUnit, JSSpec, JSpec e RSpec. [3]

Nonostante tutte le menzioni di javascript, può anche essere usato per testare le unità di un semplice modulo web.

ASP.NET

Durante lo sviluppo di un sito ASP.NET siamo stati in grado di eseguire test unitari su:

• Il dominio
• Controller / presentatori BL
• il codebehind delle pagine Web Form

A TDD è possibile tutto questo, a seconda della tua architettura. L'unica cosa che non puoi testare è il layout del file di markup.