Comprensione dei test delle unità / TDD per i Webform ASP.NET [chiuso]

Sono in un posto simile, quindi non posso offrire il miglior aiuto, e sono impaziente di vedere le altre risposte.

Ma posso consigliare entusiasticamente " The Art of Unit Testing. " È incentrato su .NET e ti darà molte idee per quello che dovresti puntare in Unit Testing.

Da quanto so fino ad ora, hai ragione a spingere il codice alle classi centrali e fuori dal codice. Sto lavorando per un'architettura più centralizzata con una migliore separazione delle preoccupazioni, simile a quella incoraggiata da MVC. (Forse vale la pena dedicare un po 'di tempo a MVC solo per familiarizzare con l'architettura. "" Non farà male neanche il curriculum.)

Prima di tutto, non dovresti assolutamente sentirti male per il fatto che stai avendo difficoltà a fare i conti con questo. WebForms non è un framework che sia mai stato progettato pensando alla testabilità, e certamente non fa nulla per rendersi facile da testare.

La prima e più importante cosa è già stata menzionata nella risposta di Jamie F. - è necessario assicurarsi che il minor numero possibile di codice sia contenuto nel codebehinds della pagina .aspx e il più possibile sia in classi di business logic separate. Il codice nel codebehinds dovrebbe essere solo il cablaggio dei controlli ASP.NET avanti e indietro, e molto poco altro. In questo modo, puoi iniziare a ottenere alcuni test unitari sulla logica aziendale esistente e sviluppare nuove logiche di business utilizzando un approccio TDD.

Per l'interfaccia web attuale, probabilmente stai meglio esaminando alcuni framework per i test di automazione del browser: WatiN e Selenium sono due che ti vengono in mente. Come prendere un approccio TDD ai test di automazione del browser, però, non lo so. A mio parere, queste tecniche sono molto più adatte per impostare i test di regressione dopo lo sviluppo.

Come altri hanno scritto, i moduli web non sono stati sviluppati tenendo presente la testabilità, tuttavia puoi rendere la tua vita molto più semplice imparando modelli come MVC, MVP e MVVM. In particolare, Web Forms funziona molto bene con MVP.

Dino Esposito ha un ottimo articolo qui su MSDN sull'utilizzo di MVP con i moduli web. Puoi anche guardare ASP.NET MVC che è stato costruito da zero prendendo in considerazione l'iniezione delle dipendenze, l'inversione del controllo, i test, ecc.

In sostanza, è necessario garantire la separazione più chiara delle preoccupazioni. Prova a esaminare la Programmazione orientata agli aspetti per formalizzarla. Eseguendo una separazione delle preoccupazioni, è molto più semplice eseguire il test delle unità, fare un'iniezione di dipendenza e tutte le operazioni necessarie per semplificare i test. Ho usato Spring in Java e hanno un modulo AOP che è anche in Spring.NET, potrebbe valere la pena dare un'occhiata.

I miei suggerimenti sono i seguenti:

• Componete l'applicazione il più possibile.
• Non mescolare la logica aziendale con la logica di visualizzazione nei moduli Web
• Guarda un modello come MVP o MVVM per i moduli web
• Considera di passare a ASP.NET MVC se rientra negli obiettivi aziendali
• Adotta l'iniezione delle dipendenze per disaccoppiare l'applicazione
• Scrivi test unitari per testare il tuo codice
• Utilizza i test di automazione per testare la tua interfaccia

Il motivo per cui suggerisco MVP / MVVM è perché questi pattern aiuteranno a far rispettare la separazione del modello di dati dalla tua vista e quindi aiuteranno a rafforzare la separazione dei dubbi.

Buona fortuna!

Il TDD è un cambiamento di paradigma ed è un tipo di test. Sembra anche che trarrai vantaggio da alcuni test unitari generali, e forse un paio di nuove "politiche" alle quali il tuo team aderirà. Un paio di cose prima di partire, assicurati che la tua squadra sia a bordo, se non lo sono, cerca di convincerle con articoli e dimostrazioni. Assicurati di includerli e ottenere il loro feedback lungo la strada.

TDD (Test Driven Development) è scrivere prima il test, quindi scrivere il codice per superare i test. E 'stato dimostrato che funziona bene, e molte persone ne sono dietro. È probabilmente più facile avviare un progetto con questo tipo di strategia piuttosto che implementarlo a metà strada senza una struttura di codice di supporto. Ci sono molte risorse disponibili là fuori su questo.

Quindi hai dei test unitari, che nel tuo caso probabilmente sono buoni da implementare prima possibile. Questo tipo di strategia ti aiuterà a testare il tuo codice. scrivi il tuo codice e poi testalo (Disponi / Agisci / Asserisci). Il test delle unità fa in modo che se fornisci l'input corretto, ottieni l'output corretto. Visual Studio disponeva di un framework di test integrato e XUnit è anche un framework di test semplice e facile da utilizzare e di facile implementazione.

Vorrei iniziare a fare pratica per iniziare a sviluppare in assembly separati che possono essere consultati dal codebehind. Ciò creerà la riutilizzabilità e inizierà verso un gradevole approccio "a strati". Cerca di utilizzare buone convenzioni di denominazione lunghe e cerca di mantenere le tue lezioni organizzate e in ordine. Neanche questo dovrebbe intralciare troppo il processo di sviluppo esistente.

IMO, il passo successivo sarebbe iniziare a identificare "raggruppamenti comportamentali" fuori dal codebase e creare interfacce di cui fuori

• Isolare metodi comuni all'interno delle applicazioni a cui tutti appartengono un'idea comune.
• Crea una classe che implementa quell'interfaccia e copia (taglia effettivamente) nel file metodi dal codebehind in modo tale da implementare tale interfaccia (quindi fare riferimento a quell'assembly e sostituire i metodi codebehind con quelli "nuovi")
• Alla fine, puoi iniziare a fare mosse interessanti con quelli interfacce compresa la facilità di testabilità (iniezione a dipendenza, contenitori IoC, ecc.)

Penso che estrarre le interfacce sia un buon punto di partenza, perché è piuttosto semplice con una base di codice esistente ei vantaggi di farlo sono piuttosto alti. ecco un buon video che parla al soggetto (BDD?) I test di integrazione sono una truffa .

Infine, consiglierei il servizio Team Foundation . Sembra che il tuo team possa entrare nella versione gratuita da quando hai 5 membri gratis. Questo aiuterà te e il tuo team a muoversi in una direzione di sviluppo organizzata oltre a darvi il controllo del codice sorgente e molte altre interessanti funzioni come il bug tracking, una "Big Board" (che è davvero interessante) e una pletora di altre buoni strumenti di gestione che sono utili per gli sviluppatori.

Spero che almeno un po 'di questo aiuti .. BUONA FORTUNA!

Sviluppo applicazioni brownfield in .NET

shows developers how to approach legacy applications with the state-of-the-art concepts, patterns, and tools developers apply to new projects.