I highly recommend not mocking your db store - the linq-to-sql conversions that have to happen can be specific to the underlying database - for instance, SQLCE only has an uppercase function, not a lowercase one, and you will find that you can extract methods from the bodies of your larger query methods which won't work server-side.
The whole point of a good unit test suite is to let you know when parts of your code don't do what you expect them to do. I used to mock my db contexts until I was bitten hard by something that compiles fine and works on in-memory collections perfectly, but didn't work at SQL Server.
It's a bit of a bigger hammer, but I recommend using one of the PeanutButter.TempDb libraries (disclaimer: I'm the author): nuget.org/packages?q=PeanutButter....
There is currently first-class support for SQL Server (via localdb), sqlite, sqlce and MySql (either via the opensource connector or via Oracle's). I'd love to add support for Firebird and Postgres, but haven't had a need to, yet; I have a feeling, from my prior use of Firebird, that it will be easy to support, but I'm not sure about Postgres. At any rate, if one of these supports an engine you're already using, I highly recommend it over mocked data contexts - one day you're going to come up against a test that works fine with code that fails horribly in production ):
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I highly recommend not mocking your db store - the linq-to-sql conversions that have to happen can be specific to the underlying database - for instance, SQLCE only has an uppercase function, not a lowercase one, and you will find that you can extract methods from the bodies of your larger query methods which won't work server-side.
The whole point of a good unit test suite is to let you know when parts of your code don't do what you expect them to do. I used to mock my db contexts until I was bitten hard by something that compiles fine and works on in-memory collections perfectly, but didn't work at SQL Server.
It's a bit of a bigger hammer, but I recommend using one of the PeanutButter.TempDb libraries (disclaimer: I'm the author): nuget.org/packages?q=PeanutButter....
There is currently first-class support for SQL Server (via localdb), sqlite, sqlce and MySql (either via the opensource connector or via Oracle's). I'd love to add support for Firebird and Postgres, but haven't had a need to, yet; I have a feeling, from my prior use of Firebird, that it will be easy to support, but I'm not sure about Postgres. At any rate, if one of these supports an engine you're already using, I highly recommend it over mocked data contexts - one day you're going to come up against a test that works fine with code that fails horribly in production ):