Il modo migliore per ripristinare il database allo stato noto tra i test di integrazione FlexUnit4?

Question

Sfondo:

Ho un'app Web Flex che comunica con un back-end Java tramite BlazeDS.Il client Flex è composto da un modulo client flessibile, che contiene le visualizzazioni e i modelli di presentazione e un modulo di servizio flessibile separato che contiene i modelli (oggetti valore) e gli oggetti servizio.

Sto scrivendo test di integrazione asincroni per RemoteObjects del modulo di servizio flessibile utilizzando FlexUnit4.In alcuni test, modifico i dati del test e li interrogo per vedere se tutto funziona (una tecnica mostrata qui: http://saturnboy.com/2010/02/async-testing-with-flexunit4)

Domanda:

Come posso reimpostare il database su uno stato noto prima di ciascun metodo di test FlexUnit4 (o catena di metodi di test)?Nei miei test di integrazione del server Java, l'ho fatto tramite una combinazione di transazioni DBUnit e Spring Test, che eseguono il rollback dopo ogni metodo di test.Ma queste integrazioni Flexunit abbracciano più richieste e quindi più transazioni.

A meno di implementare un'API del servizio di test di integrazione sul back-end, come è possibile ottenere ciò.Sicuramente anche altri si sono imbattuti in questo?Domande simili sono state poste in precedenza ( Rollback del database dopo i test di integrazione (Selenium). ), ma senza risposte soddisfacenti.

Answer 1

Ci sono diverse opzioni:

1. Se utilizzi sequenze per le chiavi primarie:Dopo che il database è stato caricato con i dati del test, eliminare il generatore di sequenze e sostituirlo con uno che inizia con -1 e conta alla rovescia.Dopo il test è possibile eliminare gli oggetti con chiave primaria < 0.Interruzioni per test che modificano dati esistenti.

   Un approccio simile consiste nel creare un utente speciale o, se lo hai created colonne timestamp, i dati iniziali devono essere precedenti a una data passata.Ciò richiede però indici aggiuntivi.

2. Utilizza un database sul server che può essere cancellato rapidamente (H2, Per esempio).Aggiungi un'API di servizio che puoi chiamare dal client per reimpostare il DB.

3. Aggiungi l'annullamento alla tua app Web.È uno sforzo notevole, ma è una funzionalità molto interessante.

4. Utilizza un database che permette di tornare indietro nel tempo con un solo comando, come Lotus Notes.

5. Non utilizzare affatto un database.Scrivi invece un server proxy che risponderà all'input corretto con l'output corretto.Aggiungi del codice al tuo real server per scrivere i dati scambiati in un file e creare i tuoi test da quello.

   Oppure scrivi casi di test che vengono eseguiti sul server reale e che creano questi file.Ciò ti consentirà di tenere traccia di quali file cambiano quando modifichi il codice sul server o sul client.

   Sul server, scrivere dei test che assicurino che esegua le modifiche corrette al DB.

6. Simile a "nessun database", nascondi tutto il codice che accede al DB in un livello DB e utilizza le interfacce per accedervi.Ciò consente di scrivere un livello mock-up che si comporta come il database reale ma che salva i dati in memoria.Sembra semplice ma di solito richiede molto lavoro.

Answer 2

A seconda delle dimensioni del vostro database di test, è possibile automatizzare i backup puliti / ripristini che ti dà l'ambiente esatto si ha su ogni prova.

Ho questo approccio in su dei miei progetti in corso (piattaforma diversa) e abbiamo anche gli script di modifica dello schema di dati di test con lo stesso approccio.

Answer 3

Sono disidratato (il mio fav scusa per carenze). Quindi scusate se questa risposta è troppo vicino alla "integrazione servizio di test API sul back-end" risposta che non volevi.

Il team che le scelte di set-up FlexUnit 'secoli fa' effettuati e soluzioni create sulla base delle nostre architetture, alcune delle quali si applicherebbe solo alla nostra infrastruttura. Le cose da considerare: 1) tutti i nostri metodi backend restituiscono stessa classe remoto mappato. 2) la maggior parte tutti i nostri metodi hanno un metodo astratto che raccontare il metodo di (o non) eseguire un "BEGIN TRANSACTION" all'inizio del metodo e un "commit di transazione" alla fine (non sono sicuro del vostro pezzo db) .

Il secondo non è probabilmente la soluzione più orientato agli oggetti, ma ecco quello che una chiamata in unità-test asincrono fa: ogni unit test chiama lo stesso metodo-wrapper, e passiamo-nel metodo-nome / package-locale, più il [...] args. Un beginTransaction è fatto. Il metodo viene chiamato, passando una falsa al metodo di test di unità FE (per ignorare le linee beginTransaction e CommitTransaction), tutto è gestito e il 'risposta' principale classe viene generato e restituito al metodo di prova unità. Un db-rollback viene eseguito e la risposta viene restituita al test di unità.

Tutti i nostri test di unità sono basati su transazioni rolling-back. Non potrei dire dei problemi che avevano durante l'impostazione che jive, ma questa è la mia comprensione generale di come funziona schtuff.

La speranza che aiuta. Comprensibile se non è così. Buona fortuna, --jeremy