Question: So am trying to do some end to end testing in specflow using entity framework 6.

I have code migrations enabled and my seed method written. I have a context factory to generate my context with a connection string that in influenced by a step definition.

What I want to be able to do is in a Feature I want to create a background step like the following

```
Given I create a database "Admin-Test"

```

In this test i want to drop all connections to a database and then drop it, followed by leaning on EF6 code migration to then recreate it and seed it with a known set of data (the default data for the application).

This all works great for the first scenario in the feature but for the rest when the database is droppde the code migrations do not run to repopulate it.

I have tried inheriting from `DropCreateDatabaseAlways<DbContext>` And this gets hit in the first but not subsequent. 

The first problem i was getting was the database not getting created, if i do that manually the seed stuff is still not being run (I read something on msdn about ef not creating the db anymore as it was confusing users).

so my question is this:
How can i get code migrations to trigger per scenario?
I suspect the question people may be able to answer easier is: how can i trigger the automatic code migration stuff manually in a unit test to force it to run?

The bonus question is this: recreating the database each scenario is inefficient - i noticed the migration generates a lot of db up and down methods. How can i run those manually and then the seed code?

Answer: 
I personally see your bonus question as part of a potential overall approach.
I dont see why `SEED` and `Migration` need to be so tightly coupled. 

A basic pattern that works with Multiple DBs.

a) By default Use Context against a DB with No initializer

```
 Database.SetInitializer(new ContextInitializerNone<MYDbContext>());
 var context = new MYDbContext((Tools.GetDbConnection(DataSource,DbName )),true); // pass in connection to db

```

b) on demand Migrate. For me this means adminsitrative trigger

```
 public override void MigrateDb() { 
   Database.SetInitializer(new MigrateDatabaseToLatestVersion<MyDbContext, MyMigrationConfiguration>());
   Context.Database.Initialize(true);
    }

```

c) Control Drops separately - Admin trigger
 You can use EF for this. I personally prefer SQL script triggered from code.

d) Trigger seed routines - Admin trigger.
 Using a rountine that can be called by a tool that just called Migrate for example.
 I dont like trying to launch this from inside EF migrations.
 Some scenarios for me that it caused headaches having EF orchestrating when seed got called.

A single Admin step could of course combine as required.

I use a custom built Migration Workbench (WPF) that can do any or all of the above on any DB. 
Including New DBs.
An approach that I have used for this is to declare a `[BeforeScenario]` method and create the database and run the migrations in here, and then in an `[AfterScenario]` method I delete the database. Its often better to put these in a seperate class specifically for setup. As long as its marked as a `[Binding]` class then specflow will find it and run the methods.

in the `[BeforeScenario]` I create by db context (`ApplicationDB`) and then create the database

```
container = TestContainerFactory.SetupContainer(id);
Database.SetInitializer(new MigrateDatabaseToLatestVersion<ApplicationDb, Configuration>());
var applicationDb = container.GetInstance<ApplicationDb>();    
if (applicationDb.Database.Exists()) //just in case the previous test didn't delete the old db
{
    applicationDb.Database.Delete();
}
applicationDb.Database.Initialize(true);

```

in the `[AfterScenario]` I delete the database

```
var applicationDb = container.GetInstance<ApplicationDb>();
applicationDb.Database.Delete();
applicationDb.Dispose();

```

The only issues I've had with this are when I am running it with a multi threaded testrunner like NCrunch, when I have had to ensure a new database gets created and deleted for each scenario and that these database all have a unique name, which I generate with a GUID.

this served me well for a while until I had too many tests that the feedback cycle became too long, at that point I allowed the tests to mock the database by having in memory collections behind the IQueryable interface of the IDbSet stuff. I made this switchable in config so that I could run the tests fast most of the time that NCrunch was running them, btu the switch back to actually running them against the database to check that that stuff still actually worked correctly.