News for hackers. Stuff that matters.
Re:SQL is 43 years old – Here’s why we still use it today by jamra on Tuesday May 02, 2017 @01:17PM (#14248339)
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.

Re:SQL is 43 years old – Here’s why we still use it today by scarface74 on Tuesday May 02, 2017 @01:37PM (#14248567)
That's much more complicated than just mocking your context in unit tests....

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.

Re:SQL is 43 years old – Here’s why we still use it today by jamra on Tuesday May 02, 2017 @02:08PM (#14248909)
Yes it is, but it's much less complicated than trying to guess what your generated SQL code will look like.
Re:SQL is 43 years old – Here’s why we still use it today by scarface74 on Tuesday May 02, 2017 @02:49PM (#14249347)
No 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.