Quali sono le migliori pratiche utilizzate per testare le query del database?

Question

Attualmente sto testando la nostra soluzione che ha l'intera "gamma" di livelli: UI, Middle e il Database onnipresente.

Prima del mio arrivo nel mio attuale team, i tester hanno effettuato manualmente test che creavano query che teoricamente restituivano un set di risultati che la procedura memorizzata doveva restituire in base a varie regole di pertinenza, ordinamento, che cosa hai.

Ciò ha avuto l'effetto collaterale di archiviare i bug sulla query del tester più spesso che sulla query effettiva in questione.

Ho proposto di lavorare effettivamente con un set di risultati noto che si potrebbe semplicemente dedurre come dovrebbe essere restituito poiché si controllano i dati presenti: in precedenza, i dati venivano estratti dalla produzione, disinfettati e quindi popolati nei nostri database di test.

Le persone insistevano ancora nel creare le proprie query per testare ciò che gli sviluppatori hanno creato. Sospetto che molti lo siano ancora. Ho in mente che questo non è affatto l'ideale e aumenta semplicemente la nostra impronta di test inutilmente.

Quindi, sono curioso, quali pratiche usi per testare scenari come questo e quale sarebbe considerato ideale per la migliore copertura end-to-end che puoi ottenere, senza introdurre dati caotici?

Il problema che ho è dove è il posto migliore per fare quali test. Devo solo colpire direttamente il servizio e confrontare tale set di dati con quello che posso estrarre dalla procedura memorizzata? Ho un'idea approssimativa, e finora ho avuto abbastanza successo, ma mi sembra che qui manchi ancora qualcosa di importante, quindi sto cercando nella community di vedere se hanno intuizioni preziose che potrebbero aiutare a formulare il mio approccio ai test meglio.

Answer 1

Il test dei proc memorizzati richiederà che ogni persona che esegue il test disponga di un'istanza separata del db. Questo è un requisito Se condividi ambienti non potrai fare affidamento sui risultati del tuo test. Saranno inutili.

Dovrai anche assicurarti di riportare il db al suo stato precedente dopo ogni test in modo da rendere prevedibili e stabili i risultati. A causa di questa necessità di ripristinare lo stato dopo ogni test, il completamento di questi test richiederà molto più tempo rispetto ai test unitari standard, quindi saranno probabilmente qualcosa che si desidera eseguire durante la notte.

Ci sono alcuni strumenti là fuori per aiutarti in questo. DbUnit è uno di questi e credo anche che Microsoft avesse uno strumento Visual Studio per professionisti del database che conteneva un po 'di supporto per i test del DB.

Answer 2

Ecco alcune linee guida:

1. Utilizza un database isolato per test unitari (ad es. nessun altro test o attività di test)
2. Inserisci sempre tutti i dati di test che intendi interrogare all'interno dello stesso test
3. Scrivi i test per creare casualmente diversi volumi di dati, ad es. un numero casuale di inserti indica tra 1 e 10 righe
4. Randomizza i dati, ad es. per un campo casuale booleano inserire e true o false
5. Tieni un conto nel test delle variabili (ad es. numero di righe, numero di verità)
6. Per gli Assert, eseguire la query e confrontarla con le variabili di test locali
7. Utilizza le transazioni dei servizi aziendali per ripristinare il database allo stato precedente

Vedere il collegamento seguente per la tecnica di transazione dei servizi alle imprese:

http://weblogs.asp.net/rosherove/articles/DbUnitTesting.aspx

Answer 3

Nell'ambito della nostra continua integrazione, eseguiamo la nostra 'build' notturna delle query del database. Ciò comporta una suite di chiamate DB che vengono aggiornate regolarmente dalle chiamate reali nel codice, nonché da qualsiasi query ad hoc prevista.

Queste chiamate sono programmate per garantire che:

1 / Non impiegano troppo tempo.

2 / Non differiscono selvaggiamente (in modo negativo) dalla notte precedente.

In questo modo, rileviamo rapidamente query errate o modifiche al DB.

Answer 4

Il pianificatore di query è tuo amico, specialmente in questo caso. È sempre buona norma verificare che gli indici vengano utilizzati quando ci si aspetta che siano e che la query non richieda ulteriore lavoro. Anche se nella tua suite sono inclusi stress test, è comunque consigliabile intercettare costose query prima che la tua app inizi a fermarsi.

Answer 5

Abbiamo un database vuoto riservato a ciascuno sviluppatore e tester.

Quando vengono eseguiti i test, ogni test cancella il database e carica i dati che prevede di utilizzare. Questo ci dà uno stato noto in ogni momento.

Possiamo quindi testare diversi scenari diversi sullo stesso DB (uno dopo l'altro) e non calpestiamo mai le dita dei piedi di un altro tester.

Questo riguarda la verifica dell'accesso ai dati stesso. Per i test di servizio facciamo praticamente la stessa cosa ma testiamo solo l'interno del servizio: in realtà non colpiamo il servizio, creiamo un'istanza della classe di elaborazione del servizio e passiamo tutto ciò di cui abbiamo bisogno. In questo modo stiamo testando il codice e non l'infrastruttura (messaggio ecc.)

Answer 6

Django offre una funzionalità di test dell'unità di database. Puoi prendere in prestito le loro idee di design e riprodurle in altri ambienti.

La gente di Django offre una sottoclasse della classe TestCase unittest standard standard che popola un database con un dispositivo noto - un set noto di righe di dati.

Nel caso di Django (e Python) è più semplice popolare il database da un estratto di dati JSON. Altri formati di file per il dispositivo possono essere utilizzati per altri framework. Ad esempio, se lavori in Oracle, potresti trovare più facile lavorare con i file CSV.

Questa sottoclasse TestCase consente di scrivere un TestCase dall'aspetto tipico che esercita il database con il dispositivo di dati noto.

Inoltre, il test runner di Django crea uno schema temporaneo a scopo di test. Questo è facile per Django perché hanno un componente completo di gestione relazionale degli oggetti che include la creazione di DDL. Se questo non è disponibile, avrai comunque bisogno dello script DDL in modo da poter creare e smaltire uno schema di test per scopi più semplici.

Answer 7

SQLServerCentral ha un articolo qui (potrebbe essere necessario registrarsi ma è gratuito e senza stringhe) su un Framework Testing Unit TSQL chiamato tsqlUnit. È open source e segue la tradizione del framework xUnit.

Segue il modello TDD SEAT:

Installazione: prepara le condizioni del test manipolando oggetti, tabelle e / o dati

Esercizio: invoca il codice di produzione

Asserisci: controlla che il risultato effettivo sia uguale al risultato atteso

Teardown - riporta tutto come prima dell'inizio del test. Questo viene effettivamente eseguito eseguendo il rollback di una transazione, che mantiene tutto in ordine.

Anche se non l'ho usato, sembra promettente ed è certamente qualcosa che guarderò più in dettaglio.

Il framework può essere scaricato qui .

Answer 8

Trovo utile testare l'SQL che viene inviato al database piuttosto che il risultato dell'interrogazione del database.

Non che non lo farò più tardi, ma lo trovo molto più veloce per testarlo piuttosto che avere il database troppo sollevato.

Answer 9

Questa è una configurazione pesante, ma raccomando contenitori TDDing.

Dopo aver eseguito lo script di test, crea un nuovo contenitore con il database in esecuzione all'interno, esegui il seeding con dati fittizi, quindi esegui le query e verifica ciò che è stato restituito e se le query hanno avuto esito positivo.

In questo modo hai il controllo su quanto vicino alla produzione l'ambiente di test.

ThoughtWorks