Development and Production databases

Question

I and my team are currently doing a project, where we are using Entity Framework 4.1 (Code First). We want to write some tests, but we don't want them to run on our primary database, as we have a team in Singapore writing a client for what we do, and they are hitting that database constantly.

So to avoid disturbance when running our tests, we would like to have a different database for testing. How do we handle a second database when using Entity Framework? We want a solution that is semi-automatic (at least), so we don't have to fiddle around with Web.config each time we need to run tests.

What kind of "tests" are you talking about? What is wrong with deploying single version for your remote team with their own database specified in deployment script (by modifying web.config)? — Ladislav Mrnka, Mar 31 '12 at 20:02
We are developing a WCF web service, and it is under serious development. Having to deploy a unique version for them (with their own Web.config) would mean, that we have to do all that manual work each time we deploy. — Nilks, Mar 31 '12 at 20:14
No it would not. Seems like you have never heard about continuous integration / deployment which is setup only once and runs automatically. — Ladislav Mrnka, Mar 31 '12 at 20:17
We do have continuous integration setup (TeamCity), and you are right: We can probably configure it to do so. But none of us are specialists in this area. — Nilks, Mar 31 '12 at 20:45

score 2 · Answer 1 · answered Mar 31 '12 at 20:07

Fiddling around with the web.config can a process that is prone to error... unless you are using web.config Transformations that is.

I would create a new configuration, "Test" for your project in Visual Studio... it can be a copy of your existing development configuration (or Debug / Release, whatever). Then, right click your Web.config file in Solution Explorer and click Add Config Transforms. Follow the instructions here on how to write a transform file. If you only need to change the EF connection string for the test environment it would look something like this in web.Test.config:

<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<connectionStrings>
    <add name="AdventureWorksEntities" 
     connectionString="metadata=.\AdventureWorks.csdl|.\AdventureWorks.ssdl|.\AdventureWorks.msl;
     provider=System.Data.SqlClient;provider connection string='Data Source=TestDB;
     Initial Catalog=AdventureWorks;Integrated Security=True;Connection Timeout=60;
     multipleactiveresultsets=true'" providerName="System.Data.EntityClient" 
    xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
</connectionStrings>

Just be sure to build under the correct configuration when you want to run your tests.

Configuration Manager

There is also a Visual Studio Add-in SlowCheetah Which makes this whole process very seamless from within the IDE.

@SayedIbrahimHashimi +1 for being the guy that "wrote the book" on MS Build and many of the tools that make my job easier. Thanks for that. — Saul Dolgin, Apr 09 '12 at 21:22

score 1 · Answer 2 · edited May 23 '17 at 12:04

Solution apprehended from this post:

//Get the connection string from app.config and assign it to sqlconnection string builder
SqlConnectionStringBuilder sb = new SqlConnectionStringBuilder(((EntityConnection)context.Connection).StoreConnection.ConnectionString);
sb.IntegratedSecurity = false;
sb.UserID ="User1";
sb.Password = "Password1";

//set the object context connection string back from string builder. This will assign modified connection string.
((EntityConnection)context.Connection).StoreConnection.ConnectionString = sb.ConnectionString;

This allows you to change connection string at runtime. There are couple of other possible solutions:

Create a wrapper property around connection string. From tests, set it to a different value.
Use #IF TEST pragmas to specify correct connection string at compile-time

Development and Production databases

2 Answers2

Linked