Actuellement, j'utilise Visual Studio 2012 RC et SQL Server 2012 RTM.
J'aimerais savoir comment ré-déployer / recréer une base de données de test pour chaque exécution de test.
Gardez à l'esprit J'ai un projet de base de données SQL Server pour la base de données à l'aide du modèle de Visual Studio 2012.
En fait, je ne suis pas très sûr d'une idée que j'ai eu dans mon esprit, mais Je suppose qu'il y a de meilleures façons de le faire et il devrait s'agir d'une solution hors de la boîte, mais je l'ignore et Google ne m'aidez pas à trouver la bonne solution.
3 Réponses :
Comme mentionné, vous voudrez probablement utiliser les scripts de configuration et de nettoyage de la Configuration et de nettoyage pour créer / déchirer la base de données SQL Server.
Pour le script, vous souhaiterez peut-être utiliser PowerShell avec un .dacpac (plutôt que simplement un script T-SQL), puisque vous utilisez un projet SSDT. Voici un lien à Quelque exemple de code - en particulier, vous voudrez peut-être jeter un coup d'œil à la commande «déployant».
Si vous n'êtes pas familier avec .dacpacs comme sortie (Build) des projets de base de données créés par SSDT, jetez un coup d'œil à cette référence link .
Merci, je vais essayer. Laissez-moi vérifier vos instructions :)
Un script PowerShell peut-il être lancé directement sous forme de script de configuration et de nettoyage?
Par exemple, que pensez-vous de l'approche de l'Aclear16 de localDB (voir son commentaire dans la question elle-même).
La solution la plus rapide, tandis qu'un peu de hack, est vraiment simple. Vous pouvez définir les propriétés de projets de base de données sous l'onglet Débogage sur "Toujours recréé dB". Ensuite, testez en deux clics, faites un débogage / construction, puis exécutez tous les tests. Vous devriez obtenir une DB fraîchement construite sur localDB pour que vos tests soient courus. Vous pouvez également modifier la cible de la DB de débogage (à nouveau les propriétés de projets de DB) à tout ce que vous voulez, vous pouvez donc déployer sur un fichier .DACPAC ou sur un DB SQL existant ou où. Cela signifie tester en deux étapes et si votre construction est longue, cela peut être ennuyeux, mais cela fonctionne. Sinon, je crois que le script est votre seule option.
Edit: Bien que cela ne réponde pas à la question d'une manière SQL Server uni, une approche de cadre d'entité facile serait la suivante: j'ai constaté que je pouvais créer et détruire ma base de données à chaque fois en utilisant le dBContext.database. CreateFnotexists () et dbcontext.database.database.Delete () dans mes phases de configuration et de nettoyage de mes tests.
Eh bien, c'est quand vous utilisez ef :)
Eh bien, il est utile que vous ayez ajouté cette information pour les futurs visiteurs! +1;)
Voulez-vous déployer et tester contre le serveur SQL ou contre localDB? Si vous reconstruisez à chaque fois, je suggérerais de tester contre localDB. Aussi, utilisez-vous TFS ou autre chose en tant qu'agent de construction? Par "Exécuter tous les tests" Voulez-vous de sélectionner manuellement pour exécuter tous les tests ou une forme d'automatisation (c'est-à-dire après chaque construction, CI, enregistrement intégré, etc.)?
@ aclear16 Je veux déployer contre SQL Server. Pour l'instant, ce n'est pas pour la construction TFS, c'est pour exécuter des tests commandés manuellement.