Migliori pratiche per l'integrazione di TDD con lo sviluppo di applicazioni Web?

Question

I test unitari e le applicazioni Web ASP.NET sono un punto ambiguo nel mio gruppo.Nella maggior parte dei casi, le buone pratiche di testing vengono dimenticate e le applicazioni web finiscono per funzionare per diversi anni senza alcun test.

La causa di questo punto dolente ruota generalmente attorno al fastidio di scrivere l'automazione dell'interfaccia utente a metà dello sviluppo.

In che modo tu o la tua organizzazione integrate le migliori pratiche TDD con lo sviluppo di applicazioni Web?

Answer 1

I test unitari saranno realizzabili se tu separa i tuoi strati appropriatamente.Come ha lasciato intendere Rob Cooper, non inserire alcuna logica nel tuo WebForm oltre alla logica per gestire la tua presentazione.Tutti gli altri livelli di logica e persistenza dovrebbero essere mantenuti in classi separate e quindi è possibile testarli individualmente.

Per testare la GUI ad alcune persone piace selenio.Altri si lamentano che la configurazione sia complicata.

Answer 2

Strato l'applicazione e almeno il test unitario dal presentatore/controller (qualunque sia la tua preferenza, mvc/mvp) al livello dati.In questo modo ho una buona copertura dei test sulla maggior parte del codice scritto.

Ho considerato FitNesse, Watin e Selenium come opzioni per automatizzare i test dell'interfaccia utente, ma non sono ancora riuscito a usarli su nessun progetto, quindi ci atteniamo ai test umani.FitNesse era quello verso cui ero propenso, ma non potevo introdurre questo così come introdurre TDD (mi rende cattivo?Spero di no!).

Answer 3

Questa è una bella domanda, a cui mi iscriverò anch'io :)

Sono ancora relativamente nuovo nello sviluppo web e anch'io sto esaminando molto codice che è in gran parte non testato.

Per quanto mi riguarda, mantengo l'interfaccia utente il più leggero possibile (normalmente solo poche righe di codice) e testare tutto il resto.Almeno posso avere una certa sicurezza che tutto ciò che arriva all'interfaccia utente è il più corretto possibile.

È perfetto?Forse no, ma almeno è ancora abbastanza automatizzato e il codice principale (dove avviene la maggior parte della "magia") ha ancora una copertura abbastanza buona.

Answer 4

Generalmente eviterei test che implicano l'affidamento a elementi dell'interfaccia utente.Io preferisco il test di integrazione, che verifica tutto, dal livello del database fino al livello della vista (ma non il layout effettivo).

Prova ad avviare una suite di test Prima scrivere una riga di codice effettivo in un nuovo progetto, poiché è più difficile scrivere i test in seguito.

Scegli attentamente cosa testare: non scrivere sconsideratamente test per tutto.A volte è un compito noioso, quindi non renderlo più difficile.Se scrivi troppi test, rischi di abbandonare quell'attività sotto il peso di una manutenzione che richiede tempo.

Prova a raggruppare quante più funzionalità possibile in un unico test.In questo modo, se qualcosa va storto, gli errori si propagheranno comunque.Ad esempio, se hai una classe che genera digest, verifica l'output effettivo, non ogni singola funzione di supporto.

Non fidarti di te stesso.Parti dal presupposto che commetterai sempre degli errori, quindi scrivi dei test per semplificarti la vita, non più difficile.

Se non ti senti bene nello scrivere i test, probabilmente stai sbagliando ;)

Answer 5

Una pratica comune è spostare tutto il codice possibile fuori dal codebehind e in un oggetto che puoi testare isolatamente.Tale codice seguirà solitamente i modelli di progettazione MVP o MVC.Se cerchi "Rhino Igloo" probabilmente troverai il collegamento al suo repository Subversion.Vale la pena studiare quel codice, poiché dimostra una delle migliori implementazioni MVP su Web Forms che abbia mai visto.

Il tuo codebehind, quando segui questo schema, farà due cose:

1. Trasferisci tutte le azioni dell'utente al relatore.
2. Eseguire il rendering dei dati forniti dal relatore.

Testare l'unità del presentatore dovrebbe essere banale.

Aggiornamento:Puoi trovare Rhino Igloo qui: https://svn.sourceforge.net/svnroot/rhino-tools/trunk/rhino-igloo/

Answer 6

Sono stati effettuati tentativi per far funzionare l'automazione dell'interfaccia utente gratuita di Microsoft (inclusa in .NET Framework 3.0) con le applicazioni Web (ASP.NET).Una società tedesca chiamata Artiso ha scritto un post sul blog che spiega come raggiungere questo obiettivo (collegamento).

Tuttavia, il loro post sul blog collega anche un webcast MSDN che spiega il framework di automazione dell'interfaccia utente con winform e dopo aver dato un'occhiata a questo, ho notato che è necessario AutomationId per ottenere un riferimento ai rispettivi controlli.Tuttavia, nelle applicazioni Web, i controlli non hanno un AutomationId.

Ho chiesto informazioni a Thomas Schissler (Artiso) e mi ha spiegato che questo era uno dei principali inconvenienti di InternetExplorer.Ha fatto riferimento a una tecnologia precedente di Microsoft (MSAA) e sperava che IE8 lo facesse meglio.

Tuttavia, stavo anche provando Watin e sembra che funzioni abbastanza bene.Mi è piaciuto anche Wax, che consente di implementare semplici test tramite fogli di lavoro Microsoft Excel.

Answer 7

Ivonna puoi testare le tue opinioni.Consiglierei comunque di spostare la maggior parte del codice in altre parti.Tuttavia, alcuni codici just appartiene lì, come riferimenti a controlli o gestori di eventi di controllo.