Un buon modo per gestire i dati del test del database?

Question

Un buon modo per gestire i dati del test del database?

#1 da (1 voti)

1

Stack LAMP standard: CentOS, Apache, PHP, MySQL più Java (tramite Google Web Tools), eclipse, mercuriale

Attualmente abbiamo una fase di integrazione manuale in cui un ramo di funzionalità viene trasferito a un server di gestione temporanea in cui il controllo di qualità esegue il test della funzionalità eseguendo il comando con la GUI. Usiamo un database di sviluppo condiviso. Stiamo incontrando il problema in cui i rami di funzionalità richiedono schemi di database diversi che creano un collo di bottiglia tra lo sviluppo del ramo di funzionalità e il test di accettazione.

Vorremmo iniziare a disporre di database separati per sviluppatori, ma non sappiamo come gestire il popolamento del database con i dati di test (l'app Web richiede una quantità di dati di base per essere presente per gli utenti) e mantenere i dati di test in sincronia con la fusione di feature branch, ecc.

Ho letto molti suggerimenti e strumenti relativi alle modifiche allo schema del database, ma non alla gestione dei dati dei test del database. Siamo solo un negozio per due persone, quindi è importante mantenere le cose semplici. Abbiamo pensato di mantenere solo script (file SQL o altro) per popolare il database di test.

Qualcuno ha risorse, storie di successo o consigli da condividere?

testing database lamp

posta DaveO 25.05.2013 - 18:04

fonte

1 risposta

Leggi altre domande sui tag testing database lamp

Albero saldo con profondità n quanti nodi ha il massimo? Rendere una classe pseudo immutabile impostando un flag

score 1 · Accepted Answer

Nel mio lavoro abbiamo due modi principali per farlo: inserimenti SQL in un pacchetto controllato dalla versione e impostazione di quanti più dati possibile tramite strumenti interni.

Poiché gli inserimenti SQL sono versioni, possiamo dirottare quelli accanto a qualsiasi aggiornamento dell'applicazione e creare un set modificato. Questo può quindi essere unito come con qualsiasi altro codice. Una parola di consiglio con questo metodo sarebbe quella di utilizzare sempre colonne con nome negli inserti SQL. Provare a correre nei tuoi dati e ottenere il "conteggio delle colonne non corrisponde all'errore" è fastidioso.

Molti dei nostri dati di test riguardano gli utenti del nostro sistema. Questo è stato impostato inserendolo manualmente, ma abbiamo esteso i nostri strumenti di amministrazione interni per consentire le impostazioni degli script. Ciò significa che manteniamo i dati dell'utente in file indipendenti dal schema (nel nostro caso, abbiamo script Perl) che utilizzano un webservice esposto dalla webapp dell'amministratore per impostare i dati del test.