30 ms·
You work from local databases. You keep a migration script that sets up the schema and another migration script that sets up the data. If you create a feature,
by jamra 9y ago
You work from local databases. You keep a migration script that sets up the schema and another migration script that sets up the data. If you create a feature, you must add to each script when merging.
You can run unit tests by creating transactions, running the test, and then rolling back at the end.
I do get your point, though. It's more convenient to be able to mock your database from your code.
- scarface74 9y agoThat's much more complicated than just mocking your context in unit tests.... https://msdn.microsoft.com/en-us/library/dn314429(v=vs.113).aspx https://msdn.microsoft.com/en-us/library/dn314429(v=vs.113).... Go down to "Testing Query Scenerios". I've wrapped the four "mockset.As" lines into one extension method to make it a lot less verbose.
- jamra 9y agoYes it is, but it's much less complicated than trying to guess what your generated SQL code will look like.
- scarface74 9y agoNo need to guess. Run all of your unit tests without mocking out your DbContext and add the following .... context.Database.Log = log.Info Where Log.info is just a method that accepts a string and take a look at the log file generated from your unit tests.