Uno scenario di test dovrebbe preparare tutti i dati richiesti? [chiuso]

Ho impostato i dati appropriati come parte dei dati. In questo modo lo scenario è completamente autonomo. Avere un database di test richiede conoscenze tacite (quali clienti sono considerati "attivi"?) O finire con i dati per casi oscuri (ho bisogno di un cliente con due acquisti precedenti e tre articoli nel loro attuale paniere). E sono d'accordo con l'altro Risposte che non dovresti mai dipendere dai dati di produzione per qualcosa di diverso dai test esplorativi o prestazionali, e anche allora i dati dovrebbero essere opportunamente disinfettati e resi anonimi per evitare incidenti.

Quando implementi i passaggi, i Givens dovrebbero fare tutto il necessario per preparare il mondo pronto per il passaggio "Quando". Ad esempio possono inserire i dati direttamente in un database. Non hanno bisogno di passare attraverso alcuna interfaccia o interfaccia utente dell'applicazione finché l'applicazione termina in uno stato coerente per verificare il comportamento a cui sei interessato (il passaggio Quando).

Il passaggio Quando dovrebbe interagire con l'applicazione esattamente come lo farebbe lo stakeholder. Quindi se lo scenario riguarda un utente che fa qualcosa, il passaggio Quando deve interagire con l'interfaccia utente. Infine, i passaggi Then eseguono tutto ciò che è necessario per verificare il risultato. Ancora una volta possono controllare i dati direttamente in un database, o controllare che i messaggi attesi siano stati emessi, ecc.

Penso che ciò consenta a Givens e Thens di "imbrogliare" in nome della convenienza, ma il passo When deve sempre giocare secondo le regole e interagire correttamente con l'applicazione.

La migliore pratica è una terza opzione. Si crea un database di test separato con contenuti conosciuti e si scrivono i test su quello.
Tra un test e l'altro un caso di test, ci si assicura che questo database di test contenga il set di dati noto e ben definito, in modo che le modifiche apportate in un caso di test non influiscano sui casi di test successivi. / p>

Non scriverei mai i miei test sul database di produzione, specialmente non test che potrebbero modificare il contenuto del database. Per la maggior parte delle aziende, i dati di produzione sono semplicemente troppo preziosi per rischiare in questo modo.

Non dovresti avere un database di lavoro di produzione per eseguire i tuoi test.

Inoltre, l'interrogazione e l'alterazione di un database di produzione durante l'esecuzione di test è in genere un'idea piuttosto negativa. Vuoi che i tuoi test funzionino in modo isolato.

Quindi, fai un cliente falso prima del test. Usalo. Cancellalo. Se la creazione è troppo complessa, è possibile preparare un intero database a scopo di test. Dovrebbe avere la stessa struttura del database di produzione. Quindi dovresti solo avviare test usando questo stesso database.

A scopo di test, fai piccoli passi. Penso che il modo migliore sia quello di preparare lo scenario con il database falso e piccolo invece del vero database di produzione. Puoi copiare alcune delle righe e non appena riesci, prova i dati reali.