Struttura consigliata per testare Javascript con QUnit in ASP.NET

Question

Ho una soluzione standard ASP.NET MVC (versione 2 anteprima 2) con i test di progetto e unità lato server effettivi in ​​progetti separati.

Poiché questo progetto è molto pesante sul lato client, desidero creare un progetto ClientTest che utilizzi QUnit per testare il progetto principale.

Ho pensato di creare un progetto di webforms ASP.NET regolare con un singolo file HTML che caricasse i vari script nella mia directory Scripts/e li testasse con QUnit. Sfortunatamente questo genererà un altro server di sviluppo ASP.NET. Potrei configurare la porta del server di progetto MVC in esecuzione prima di eseguire i test, ma ci deve essere un modo migliore che non sia solo il lancio del file html di test nel progetto MVC principale.

Qualcuno sa di un modo migliore di andare su questo?

Answer 1

Mi piace l'idea di inserire i test QUnit in un progetto separato. Che ne pensi di usare XCOPY per copiare gli script nell'evento pre-build?

Dite il vostro progetto MVC è MyProj.Web e il vostro progetto di test QUnit è MyProj.ClientTest (sostituire con i vostri nomi di progetto).

• Creare una cartella Scripts nel progetto ClientTest.

• Da Progetto>MyProj.ClientTest Proprietà> Eventi di generazione, aggiungere il seguente al pre-build riga di comando evento:

  XCOPY "$ (SolutionDir) MyProj.Web \ Scripts" " $ (ProjectDir) Script "/ S/Y

• Quindi nel codice HTML includere solo i file JavaScript appropriati dalla cartella Scripts.

Nota: Si dovrà ricostruire il progetto ClientTest per aggiornare i file JavaScript quando si desidera eseguire nuovamente i test. Regola i nomi delle cartelle, i percorsi e le opzioni XCOPY secondo necessità.

Answer 2

Forse potresti scegliere le tecniche da this article, compreso l'utilizzo della riga di comando, sfruttando NUnit con WatiN e raschiando i risultati dei test per i rapporti. Questa soluzione non richiederebbe un progetto WebForms separato per sfruttare i test in quanto è gestito da WatiN.

Answer 3

Non è troppo chiaro per me perché l'utilizzo di MVC fa la differenza: se si desidera integrare i test in una build CI, il suggerimento di gWiz è la strada da percorrere.

Se si desidera eseguire i test in modo interattivo direttamente sulla pagina reale senza influire sull'aspetto di tale pagina, è possibile controllare il plug-in FireUnit per Firebug. È inoltre possibile eseguire il wrapping di FireUnit su QUnit come descritto in John Resig's blog.

Se si è preoccupati di includere elementi di prova, includere gli script pertinenti nelle build di test/debug e disabilitarli/rimuoverli nei build di produzione.