stringa di connessione nel progetto di unit test per fare riferimento database in App_Data cartella

Question

Sto cercando di fare riferimento il mio file di database nel mio progetto unit test. Questa è un'applicazione ASP.NET MVC.

Si prega di notare: Lo so che non dovrei essere l'accesso al database nel mio test di unità, ma questo è per una soluzione rapida su un test che ho bisogno di avere passaggio solo ora.

Dopo la prossima pietra miliare sarò beffardo i metodi di accesso al database, ecc

Quindi ecco la mia stringa di connessione nel mio MVC config web app ei file ap.config unit test

<add name="DBConnectionString" connectionString="Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\DB.MDF;Integrated Security=True;User Instance=True" 
    providerName="System.Data.SqlClient" /> 

Quando corro il test ottengo un errore:

Test method 
ED.Tests.Controllers.CandidateControllerTest.PersonalDetailsStepPostShouldRedisplayIfNoSurnameSupplied 
threw exception: System.Data.SqlClient.SqlException: 
An attempt to attach an auto-named database for file C:\Users\Desktop\ED\TestResults\LAPTOP-D 2009-07-22 18_16_20\Out\DB.MDF failed. 
A database with the same name exists, or specified file cannot be opened, or it is located on UNC share. 

mi sembra la stringa di connessione è sbagliato, ma non sono sicuro di come impostare il percorso corretto. Ho provato ad aggiungere \ .. \ .. ed i nomi delle directory, ecc

Answer 1

MSTest verrà eseguito l'assembly unit test in una cartella completamente diversa su ogni prova. L'idea è che ogni corsa è un caso completamente isolato dalle precedenti e successive esecuzioni. In realtà è un po 'un problema dire di copiare i file di dati insieme al resto della tua applicazione. È necessario fare clic con il tasto destro del mouse sulla soluzione (non sul progetto), scegliere aggiungi, creare una nuova configurazione di esecuzione del test. Quindi è necessario modificare la configurazione dell'esecuzione del test e specificare quali file verranno copiati nella cartella di esecuzione del test. Dovrebbe essere presente una directory di pari livello nella directory della soluzione denominata TestResults che contiene le cartelle utilizzate per ogni esecuzione di test.

Answer 2

commento alla risposta di Craig: Non dovrebbe essere un dolore per distribuire i file di dati aggiuntivi per l'esecuzione di test di unità. È possibile utilizzare DeploymentItemAttribute (Microsoft.VisualStudio.TestTools.UnitTesting) a livelli di classe o un metodo per specificare i file devono essere copiati prima di eseguire questi test.

Answer 3

si può semplicemente riferimento LocalDB come questo:

<add name="DefaultConnection" 
connectionString="Server=(localdb)\v11.0;Database=WebPortalDb" providerName="System.Data.SqlClient"/> 

dove WebPortalDb è il nome del database.

Answer 4

La risposta migliore è di non connettersi a un database a tutti con alcune unit test, e invece prendere in giro il database. Tuttavia, potrebbe essere necessario refactoring codice MVC esistente per arrivare a un punto in cui si può prendere in giro una dipendenza del database e non si dovrebbe mai refactoring fino a quando il codice non viene avvolto in alcuni test. Quindi in quella situazione, sì - probabilmente dovrai collegare il tuo progetto di test al database, almeno per un po ', finché non decoderai tutto quanto basta per abilitare il mocking.

Quindi nel mio caso stavo usando ASP.Net MVC 5. Ciò significava che avrei potuto ottenere la configurazione di Entity Framework necessaria al file app.config di Unit Test Project semplicemente facendo clic con il pulsante destro del mouse sul file della soluzione, gestendo NuGet per Soluzione e aggiunta di EF al progetto di test.

Quindi aggiungendo la stringa di connessione dal file web.config principale del progetto MVC QUASI lavorato, con il tweak minore che ho dovuto togliere la parte finale della stringa che ha detto:

AttachDbFilename=|DataDirectory|<<MY_DATABASE_NAME_AND_ID>>.mdf 

Come ho Ad esempio, creare test "Unit" che si connettono a un database non è la strada da percorrere, quindi questa sarà solo una misura temporanea.Ma il codice ha bisogno di refactoring per portarlo a uno stato burlone, e (s) lui che refactoring senza almeno alcuni test per dimostrare che il refactoring non ha rotto tutto sta andando in crociera per un livido.