Come automatizzare test funzionali/di integrazione e rollback del database

Question

In contrasto con il mio previous question, proverò a soddisfare i miei requisiti.

io sto cercando di trovare un quadro di riferimento/metodologia/"cosa" che si adatterebbe il seguente:

• Capacità di scrivere un test automatico, preferibilmente scritto in Visual Studio, utilizzando C#.
• Il test dovrebbe guidare un browser web e interagire con SUT proprio come farebbe un utente.
• Il test deve essere in grado di configurare uno scenario di test in DB.
• Il test deve essere in grado di affermare che le interazioni dell'utente hanno avuto l'effetto previsto in DB.
• Al termine del test, dovrebbe essere in grado di ripristinare tutte le modifiche apportate in DB.

Il mio primo tentativo è stato quello di utilizzare il test NUnit per guidare Selenio (e Watin prima), ma ho affrontato un po 'un problema (controllare il link qui sopra) durante l'utilizzo di TransactionScope per ripristinare le modifiche del browser Selenio-driven fatto nel DB.

Qualcuno ha mai fatto qualcosa del genere nel "mondo reale"? Ho trovato alcuni riferimenti tramite Google, ma non sono riuscito a trovare esempi concreti su come implementarlo. Non ci sarebbero problemi se dovessi fare un test unitario. In tal caso TransactionScope sarebbe abbastanza.

Modifica: R. Harvey mi ha indirizzato alla domanda this, che è quasi identica alla mia situazione.

Tuttavia questa domanda è solo quasi uguale a. La mia applicazione fa parte di una famiglia di servizi, tutti che accedono allo stesso insieme di tabelle del database. La quantità di dati di test richiesti non consente un uso efficiente di drop/create-scripts, quindi esiste una soluzione alternativa per questo?

Stiamo utilizzando SQL Server 2005 e non sono molto esperto in database magic, quindi se c'è un modo per utilizzare lo scripting sql diverso da drop/create, allora quella potrebbe essere un'opzione.

Edit 2:

Sulla base delle risposte e qualche testa supplementari graffi, andremo per i database più leggeri per gli sviluppatori di eseguire unit, collaudo profilo dell'integrazione e funzionali. Questo ci consente di utilizzare gli script sql per impostare e abbattere il test.

Answer 1

Le modifiche apportate in una transazione sono visibili solo all'interno di detta transazione. Anche il wrapping del test in ambito di transazione (se possibile) farebbe sì che il test si comportasse in modo diverso rispetto a quello reale in un aspetto molto critico (transazioni).

È molto meglio utilizzare un'immagine di database ripristinata prima di ogni suite di test. In questo modo, una volta completata la suite e completata la verifica, si rilascia il database di test. Alla prossima esecuzione, durante l'installazione della suite, il database viene ricreato dall'immagine salvata in uno stato pristino pronto per essere testato. Ancora meglio sarebbe avere uno script che distribuisca il database da zero ed esegua quello script durante l'installazione della suite.

Btw non è possibile ripristinare lo stato prima di ogni test. Più genericamente non è possibile avere lunghe fasi di configurazione e pulizia del test individuale.Man mano che si aggiungono altri test, il tempo trascorso a ripristinare il database in condizioni pronte per i test tra i test diventerà semplicemente ingestibile. Le suite con centinaia di test sono abbastanza comuni e le analisi complete di decine di migliaia di test implicano ore e ore di recupero del database per il test. Progetta il tuo test individuale in modo che possano essere eseguiti indipendentemente, ad es. il test N deve produrre risultati validi anche se il test N-1 fallisce.

Un'altra cosa da considerare è indagini fallimento, si desidera che il test fallito di lasciare il database in uno stato che può essere indagato per informazioni significative e si desidera test successivi siano in grado di funzionare e produrre risultati validi. A volte questi requisiti si contraddicono a vicenda, ma è necessario tenerli in considerazione e progettare il test intorno a loro.

Answer 2

Se la quantità di dati richiesta per ripristinare il database a uno stato noto buono è proibita per gli script drop/create e si eseguono test su Developer o Enterprise Edition di SQL 2005, è possibile esaminare creating a database snapshot del buono stato, e reverting to it prima di ogni test. Questo è considerevolmente più veloce di un ripristino completo, anche se potrebbe essere ancora troppo dispendioso in termini di tempo se si dispone di centinaia di test.

Answer 3

Da non perdere Amnesia che ho consigliato su this related question.