Come dovrei manipolare il database da un test di integrazione?

2

Ho un test di integrazione che deve modificare alcuni valori nel database. Questo tipo di modifica non è necessaria per l'applicazione reale, ma solo per configurare lo scenario di test.

Il dilemma:

Dovrei manipolare il DB direttamente dal progetto di test (eseguendo una query SQL personalizzata o aggiungendo EF al progetto di test), o dovrei aggiungere metodi ben definiti al modello BL / Domain / DAL che non hanno vero scopo diverso dall'aiutare quei test di integrazione? C'è un modo migliore per raggiungere questo obiettivo?

    
posta BornToCode 12.12.2017 - 10:04
fonte

3 risposte

3

Questo non è un dilemma. Non c'è motivo di contorcersi per evitare metodi di test.

La tua suite di test è una componente vitale della base di codice: il fatto che non sia spedito al cliente è irrilevante. Tutte le migliori pratiche appropriate per il codice commerciale sono comunque appropriate anche per il codice di test. Pertanto, se la soluzione ragionevole per realizzare qualcosa in modo trasparente, efficiente e manutenibile è creare un metodo per esso, quindi creare tale metodo. Che il metodo sia o meno in produzione non dovrebbe essere un fattore in questa decisione.

    
risposta data 12.12.2017 - 10:07
fonte
1

In generale, è preferibile impostare l'apparecchiatura tramite l'API pubblica. Se questo non è il caso, è accettabile anche l'accesso diretto a db come backdoor di test. In alternativa, possiamo anche usare Apparecchio precostruito , ci sono molti modi per farlo come sql popolamento, data pump, ecc. Tutte queste configurazioni delle fixture hanno la stessa sfida: l'attrezzatura si abbatte. Teardown automatizzato può aiutarti a configurare e abbattere il caso tramite l'API. In Prebuilt Fixture, forse dovresti usare un meccanismo di flashback del database.

Un altro pensiero è che, sebbene nella tua domanda, tu pensi che il test di integrazione debba avvenire attraverso il database. Tuttavia, non è sempre necessario il caso. A causa della difficoltà di installazione e rimozione, dovremmo sempre provare a umiliarlo . Se il tuo codice ha già un pattern di repository, puoi semplicemente implementare una mappa hash in memoria per l'archivio dati. La bellezza di ciò è che puoi fare affidamento su Teardown raccolto in modo irregolare . In caso contrario, prova a utilizzare il database in memoria, quindi non è necessario pulire i dati creati dai test.

    
risposta data 12.12.2017 - 10:50
fonte
0

Se i dati sono richiesti solo per un test specifico, questo viene generalmente ottenuto tramite una transazione che viene ripristinata alla fine del test. C # ha TransactionScope per questo scopo. Suppongo che altre lingue abbiano costrutti simili.

Il vantaggio di questo approccio è che non ti devi preoccupare di abbattere. Basta impostare i dati (organizzare), fare il test (agire) e verificare che il test abbia funzionato (asserire). Questo diventa super-importante se il test dovesse essere eseguito inavvertitamente su un database live (sì, l'ho visto accadere!).

    
risposta data 12.12.2017 - 10:07
fonte