Infissi e selenio e rotaie (oh mio?)

Question

Quali dati utilizzate con i test Selenium sulle app Rails? Carica da infissi? Utilizzare un dev db esistente? Utilizzare un db separato (senza fixture)?

Sto considerando le mie opzioni qui. Ho un'app Rails con una grande suite di test Selenium che funziona su una versione modificata di Selenium Grid. Parte del processo, in questo momento, sta caricando una serie di dispositivi di grandi dimensioni, una volta, prima che la suite di test venga eseguita. È un sacco di dati. La maggior parte di esso riporta informazioni esportate dalla nostra produzione db. Quando l'ho impostato in origine, ho esportato i dati su yaml da Oracle.

Ora c'è stato un cambiamento di schema in alcune delle tabelle di rapporto, quindi ovviamente devo rigenerare i dati del dispositivo. C'è così tanto che non vale la pena di modificare i file a mano. Ma sembra inefficiente dover rigenerarsi per ogni piccolo cambiamento di schema - senza contare che è ancora un altro passo da ricordare. C'è un modo migliore?

MODIFICA: Originariamente intendevo caricare i dispositivi prima di ogni test e scaricarli dopo ogni test, come i normali test di Rails. Ma ci vogliono circa 15 minuti per caricare i proiettori a causa di questi dati di segnalazione. Ci sono più di 200 test e la suite funziona ogni 12 ore. Non riesco a piegare capitano dello spaziotempo!

EDIT 2: Sono anche d'accordo sul fatto che avere questa grande serie di proiettori è un cattivo odore. Non sono sicuro di come ridurlo, perché i report aggregano molti dati e gran parte del valore dei test del selenio è che testano i report.

Anche se si tratta di un piccolo insieme di dati, anche se ... è ancora un altro set da mantenere coordinato con le modifiche dello schema. (Abbiamo un set separato, più piccolo per i test di integrazione di unità, funzionali e [Rails].

Che mi riporta alla mia domanda iniziale: ci sono altre opzioni oltre a farlo a mano, o ricordando di rigenerarle ciascuna tempo?

Answer 1

Se possibile, la cosa migliore da fare è disporre di un sistema in cui ogni test del selenio ottiene il proprio stato dei dati (ad esempio: tabelle DB eliminate e ricreate, dati di bootstrap reinseriti e cache eliminate). Questo è più facile a dirsi che a farsi e di solito è possibile solo se il progetto lo prevede sin dall'inizio.

La cosa migliore è avere uno stato DB coerente per ogni suite di test/corsa. Questo non è così bello dato che ora c'è una forte possibilità che alcuni test dipenderanno dal successo dei test eseguiti in precedenza, rendendo più difficile identificare i veri fallimenti rispetto ai falsi negativi.

Il caso peggiore, IMO, consiste nell'utilizzare un DB statico in cui ogni esecuzione di test muta la data. Questo porta quasi sempre a problemi e di solito è un "odore del progetto".La chiave per farlo "nel modo giusto" (di nuovo, IMO) è essere vigili su qualsiasi cambiamento di stato/schema e catturarlo come parte del processo di test/build automatico.

Rails fa un buon lavoro con questo già con Migrazioni, quindi approfittane! Senza conoscere la tua situazione, in genere metterei in dubbio la necessità di eseguire test Selenium contro uno snap del DB completo. La maggior parte dei DB può essere (o dovrebbe) essere ridotta a meno di 1 MB per i test automatizzati, rendendo le migrazioni degli schemi automatizzate e il ripristino dei dati molto più efficienti.

L'unica volta che ho visto un motivo "valido" per DB massivi per i test del selenio è quando il DB stesso contiene grossi blocchi di "dati logici" in cui i dati influiscono sul flusso dell'applicazione (si pensi all'interfaccia utente basata sui dati).

Answer 2

Sono attualmente impegnato in un progetto con un'enorme suite di test Selenium - in realtà, per la quale è stato scritto il Selenium Grid - ei nostri test utilizzano una piccola quantità di dati di riferimento (sebbene non utilizziamo i dispositivi Rails YAML) e fabbriche di oggetti per dati una tantum necessari per test particolari.

In alternativa, in molti dei progetti ThoughtWorks Rails in cui ho lavorato abbiamo scritto script di controllo che incorporano un numero di hook di pre-commit, ad esempio eseguendo i test prima di consentire un commit. Una cosa che si potrebbe considerare è la scrittura (o la personalizzazione) di uno script di controllo simile che verificherà le modifiche dello schema e ricaricherà i dati di riferimento secondo necessità.

Vedere ad es. Paul Gross's rake commit tasks su Github.

Answer 3

Credo che tu stia chiedendo due domande qui che si intrecciano così se io sono una scomposizione:

• che si desidera ottenere dati di prova dentro e fuori del vostro DB in modo rapido ed infissi non sono farlo per te.
• Sei stato bruciato da una modifica dello schema e si vuole fare in modo che tutto quello che fate non richiede otto iterazioni a tema "giocherellare con i dati di test ... ancora" :)

You' Ho un paio di alternative qui che ho mostrato qui sotto. Perché hai citato Oracle sto usando tecnologie Oracle qui, ma la stessa cosa vale per le altre piattaforme DB (ad esempio PostgreSQL):

1. tesks Rake che chiamano script PL/SQL per generare i dati, brutto orribile del male idea, non farlo a meno che non ci sia altra opzione. L'ho fatto su un progetto che aveva bisogno di caricare miliardi di righe per alcuni test di architettura dell'infrastruttura. Ne continuo ancora il broncio.
2. Ottieni il DB in formato dump. Per discariche di dati binari veloci, controlla le utility exp/imp e data pump. Ciò ti consentirà di configurare e rimuovere rapidamente il tuo DB. Sicuramente su un progetto di rotaie su cui ho lavorato, abbiamo utilizzato le attività di rake per esp/imp un database con circa 300.000 di record in meno di un minuto. Controllare anche SQL Loader, che è l'utilità di dump logico, poiché la sua logica è più lenta e richiede di avere script di controllo per aiutare SQL Loader a comprendere i dump. Tuttavia, il vantaggio del dump logico è che è possibile eseguire script di trasformazione su di essi per massaggiare i dati nel formato più recente. Purtroppo, proprio come gli apparecchi, tutti questi strumenti sono piuttosto sensibili ai cambiamenti nello schema.
3. Utilizzare un plug-in come Machinist o Factory Girl per rendere più gradevole la generazione dei dati. Continuerai ad applicare la penalità di utilizzare ActiveRecord per configurare il DB, ma questi generatori di oggetti fasulli ti aiuteranno a rimanere vicino alle tue migrazioni e sono molto meno fastidiosi da gestire rispetto alle fixture.
4. Combina approcci 2 e 3. Quello che succede qui è che si fanno alcuni dati di test con dire Machinst. Si esportano i dati di test in un dump e quindi si ricarica il dump durante ogni esecuzione di test. Quando lo schema cambia aggiorna la configurazione di Machinist e la riesporta.

Speranza che aiuta.