title: Mocking EF6 database context
body: <p>I have a lot of instantiations of the DB context in my methods, like:</p>
  
  <pre><code>using (myEntities context = new myEnties())
      [do something with the context...]
  }
  </code></pre>
  
  <p>I learn now, that my code is legacy code because it is lacking unit tests. To make my code testable, I would need to inject the context somehow, maybe via the constructor of the class. I would then maybe use Effort.EF6 or something to mock the context.</p>
  
  <p>However, first I have to get away from constructing the context locally. But here is my question: when I started with EF a long time ago, I learned that it was a very good idea to have a short living context (while in the good old ADO days one would think twice about releasing a connection once established). Is it really a good idea to store the context in a field and not release it at all (a practice I saw even in MS code examples)? Does it release itself and "using" is not required?</p>
  
  <p>On a side note: I could alternatively use integration tests and just provide the original connection and set up test data etc. I would then not need to refactor hundreds of "using" statements. This of course would slow the tests but it would also test my database (I am using a lot of stored procedures). Is this a feasible approach then?</p>