LocalDb seems like a good choice as a storage mechanism for running integration tests.
Some general guidelines would be:
By default, the database file is set to "Copy always" to output directory so no action required there. This means that it will be in our output directory when the project is built, and we can note that this is the location we will use in the connection string next.
Using SQL Server 2012 LocalDb in VS11 and VS2010 for testing (link)
Some general guidelines would be:
- Add a service-based database to a project;
- Set the DbContext's connection string to use LocalDb engine with this database;
- Populate the database prior to use (static data, test-specific data);
- Run tests.
Add a Database to a Project
In Visual Studio, right-click on a (test) project and select Add -> New Item… -> Visual C# Items -> Data -> Service-based Database. The assumption is that we already have a working code, using a real database. Hence there is an existing context. So, during the creation of the database file we will not generate any db-access code automatically (press Cancel in the wizard) or we will delete the auto-generated code after it is added to the project.By default, the database file is set to "Copy always" to output directory so no action required there. This means that it will be in our output directory when the project is built, and we can note that this is the location we will use in the connection string next.
Set Connection String
(to be continued...)
References:
Developer goodness - LocalDb (link)Using SQL Server 2012 LocalDb in VS11 and VS2010 for testing (link)
No comments:
Post a Comment