Entity Framework includes the ability to intercept execution of database commands, giving a developer a great amount of power. You will find a detailed list of things you can do with interception on MSDN, https://msdn.microsoft.com/en-us/data/dn469464.aspx.
Why should you care? What would you do with this capability?
You have the ability to capture the generated SQL being sent through EF. Capturing this SQL can be used for debugging purposes. It can be sent to the console, read in a debugger, or even written to a database. Although this might be verbose, it could be used as a sort of audit, should that be required.
You also have the ability to modify the SQL being sent, trap or set exceptions, or even trap or set results. One example provided on MSDN was the capture of the SQL and pushing it into a queue for processing in a batch manner, and replacing the result with success. The application sees this as success, while the actual activity is delayed for later processing.
I could see using this capability for a mock implementation. You could wire up a result set and send it back from an EF call, replacing the original Request and Response. I’m not sure this is a good way to create mock results.
There is so much you can do with this interception capability. It is worth your time to take a look at the MSDN document. Are you using interception? If so, why not get into the conversion by leaving your comment.
Cheers,
Ben