Comments on: Unit testing an Entity Framework DAL part 1: Just hit the database http://graemehill.ca/unit-testing-an-entity-framework-data-access-layer-part-1-just-hit-the-database Sun, 05 Feb 2012 16:45:19 +0000 http://wordpress.org/?v=2.7 hourly 1 By: Unit testing an Entity Framework DAL part 2: Rolling back the test database | Graeme Hill's Dev Blog http://graemehill.ca/unit-testing-an-entity-framework-data-access-layer-part-1-just-hit-the-database/comment-page-1#comment-1435 Unit testing an Entity Framework DAL part 2: Rolling back the test database | Graeme Hill's Dev Blog Fri, 28 Oct 2011 03:14:41 +0000 http://graemehill.ca/?p=119#comment-1435 [...] « Unit testing an Entity Framework DAL part 1: Just hit the database Converting from SVN to Git [...] [...] « Unit testing an Entity Framework DAL part 1: Just hit the database Converting from SVN to Git [...]

]]> By: ShantiDev http://graemehill.ca/unit-testing-an-entity-framework-data-access-layer-part-1-just-hit-the-database/comment-page-1#comment-707 ShantiDev Tue, 13 Jul 2010 12:48:27 +0000 http://graemehill.ca/?p=119#comment-707 Firstly thanks for this contribution I think this is a critically important aspect of TDD, Agile Development and Automated Testing which is not adequately covered in most books, articles and blogs. Although your blog is specific to Entity Framework, I think it is worth looking at other Solutions and seeing how these could be adapted to Entity Framework or how Entity Framework could be adapted to make testing without actually hitting the DB simpler. We all accept that as part of your test pack there are going to be integration tests and Acceptance tests that actually hit the Database. In my experience there are a whole range of tests (Call them integration tests if you want) that need to persist some objects and load them again. Projects with complex processing logic etc. In all these cases you either need a database or you need to be able to Fake a data access layer. If you are using a framework such as Habanero or NHibernate this should be relatively simple since these pretty much ensure that database differences are accounted for. Habanero uses an InMemoryDatabase which is a Fake it behaves exactly like a real database as far as Habanero is concerns and implements all the same constraints etc. I have used this on my last few projects and found it to be incredibly simple, usable and resulted in incredibly fast tests with no test interactions etc. It worked so well that when I touch an old project I automatically change to using the InMemory The In Memory Database just stores the objects. You don't need to propogate schema changes to it etc etc. It was obviously a bit of work to create but the Habanero guys have already done it. The unintended benefits of using the In Memory database for Agile developement is that we have found that we are doing large chunks of development using just Business Objects and the In Memory database (No adding removing columns/Table etc from the Database). Even the visual testing by the developer is done using an In Memory Database. When you go into stabilisation i.e. testing by testers before deployment we generate the DB Schema and run our Database integration and acceptance tests and then do visual testing. Sorry for the long reply but I have found this feature incredibly usefull and very supportive of Agile development and I would like to see it incorporated into other frameworks. Shanti Dev Firstly thanks for this contribution I think this is a critically important aspect of TDD, Agile Development and Automated Testing which is not adequately covered in most books, articles and blogs.

Although your blog is specific to Entity Framework, I think it is worth looking at other Solutions and seeing how these could be adapted to Entity Framework or how Entity Framework could be adapted to make testing without actually hitting the DB simpler.

We all accept that as part of your test pack there are going to be integration tests and Acceptance tests that actually hit the Database.

In my experience there are a whole range of tests (Call them integration tests if you want) that need to persist some objects and load them again. Projects with complex processing logic etc.

In all these cases you either need a database or you need to be able to Fake a data access layer.

If you are using a framework such as Habanero or NHibernate this should be relatively simple since these pretty much ensure that database differences are accounted for.

Habanero uses an InMemoryDatabase which is a Fake it behaves exactly like a real database as far as Habanero is concerns and implements all the same constraints etc.

I have used this on my last few projects and found it to be incredibly simple, usable and resulted in incredibly fast tests with no test interactions etc. It worked so well that when I touch an old project I automatically change to using the InMemory
The In Memory Database just stores the objects. You don’t need to propogate schema changes to it etc etc.

It was obviously a bit of work to create but the Habanero guys have already done it.

The unintended benefits of using the In Memory database for Agile developement is that we have found that we are doing large chunks of development using just Business Objects and the In Memory database (No adding removing columns/Table etc from the Database). Even the visual testing by the developer is done using an In Memory Database. When you go into stabilisation i.e. testing by testers before deployment we generate the DB Schema and run our Database integration and acceptance tests and then do visual testing.

Sorry for the long reply but I have found this feature incredibly usefull and very supportive of Agile development and I would like to see it incorporated into other frameworks.

Shanti Dev

]]> By: Graeme http://graemehill.ca/unit-testing-an-entity-framework-data-access-layer-part-1-just-hit-the-database/comment-page-1#comment-699 Graeme Tue, 22 Jun 2010 15:23:06 +0000 http://graemehill.ca/?p=119#comment-699 zen: I acknowledged that it is technically an integration test in the article: "it isn’t really a unit test. It is actually an integration test" My point was that is some cases it makes more sense to only do integration tests. Maybe I should have made it more clear in the title. Marcus: I'm glad to see that is working well. The only thing I would be worried about is that NHibernate may behave differently with each DBMS in some cases. However, it the behaviour is consistent then that is probably a great solution. zen: I acknowledged that it is technically an integration test in the article:
“it isn’t really a unit test. It is actually an integration test”
My point was that is some cases it makes more sense to only do integration tests. Maybe I should have made it more clear in the title.

Marcus: I’m glad to see that is working well. The only thing I would be worried about is that NHibernate may behave differently with each DBMS in some cases. However, it the behaviour is consistent then that is probably a great solution.

]]> By: Marcus Malmgren http://graemehill.ca/unit-testing-an-entity-framework-data-access-layer-part-1-just-hit-the-database/comment-page-1#comment-698 Marcus Malmgren Tue, 22 Jun 2010 14:59:18 +0000 http://graemehill.ca/?p=119#comment-698 I have used an in memory database with SQLite together with NHibernate. It was extremely quick. We used the repository pattern so all the queries could be unit tested. I see what you mean about them beeing integration tests, but I don't fully agree. They test the queries (criterias in Nhibernate, could be linq) of the repositories but that doesnt mean it will work with the real DBMS. Additional integration tests against the real DBMS should also exist to guarante the functionality. I have used an in memory database with SQLite together with NHibernate. It was extremely quick. We used the repository pattern so all the queries could be unit tested. I see what you mean about them beeing integration tests, but I don’t fully agree. They test the queries (criterias in Nhibernate, could be linq) of the repositories but that doesnt mean it will work with the real DBMS. Additional integration tests against the real DBMS should also exist to guarante the functionality.

]]> By: zen http://graemehill.ca/unit-testing-an-entity-framework-data-access-layer-part-1-just-hit-the-database/comment-page-1#comment-662 zen Fri, 28 May 2010 13:45:07 +0000 http://graemehill.ca/?p=119#comment-662 you're missing the point. the reason why you don't hit the actual database is that you're testing logic and not connection. if, for whatever reason, you get a timeout loading the data the test will fail even if your logic is not faulty and that produces a false negative. you database connection and reading / writing should be done in an integration test. logic should be tested in its own unit test. the only way they should feature together is in a test sequence that is rolling up multiple tests together. furthermore: in reality you may have a _lot_ of unit tests and hitting a database is slower than a mock object. unit tests are meant to be run often and any speed increase will save frustration. admittedly there should be tests that hit the db and test all functionality but they're not unit tests and should run as often as your unit tests run. you’re missing the point. the reason why you don’t hit the actual database is that you’re testing logic and not connection. if, for whatever reason, you get a timeout loading the data the test will fail even if your logic is not faulty and that produces a false negative.
you database connection and reading / writing should be done in an integration test. logic should be tested in its own unit test. the only way they should feature together is in a test sequence that is rolling up multiple tests together.
furthermore: in reality you may have a _lot_ of unit tests and hitting a database is slower than a mock object. unit tests are meant to be run often and any speed increase will save frustration.
admittedly there should be tests that hit the db and test all functionality but they’re not unit tests and should run as often as your unit tests run.

]]> By: Marcus Malmgren http://graemehill.ca/unit-testing-an-entity-framework-data-access-layer-part-1-just-hit-the-database/comment-page-1#comment-658 Marcus Malmgren Wed, 26 May 2010 18:09:46 +0000 http://graemehill.ca/?p=119#comment-658 Ok, thanks for your answer. I agree, that is not worth the effort. And it will also require POCO. Ok, thanks for your answer. I agree, that is not worth the effort. And it will also require POCO.

]]> By: Graeme http://graemehill.ca/unit-testing-an-entity-framework-data-access-layer-part-1-just-hit-the-database/comment-page-1#comment-655 Graeme Tue, 25 May 2010 17:00:34 +0000 http://graemehill.ca/?p=119#comment-655 It was theoretical. You might have to make two entity models (one for each provider) and then make both object contexts implement the same interface and resolve instances with an IOC framework. Probably isn't worth the effort though. It was theoretical. You might have to make two entity models (one for each provider) and then make both object contexts implement the same interface and resolve instances with an IOC framework. Probably isn’t worth the effort though.

]]> By: Marcus Malmgren http://graemehill.ca/unit-testing-an-entity-framework-data-access-layer-part-1-just-hit-the-database/comment-page-1#comment-653 Marcus Malmgren Tue, 25 May 2010 15:52:10 +0000 http://graemehill.ca/?p=119#comment-653 I don't think its possible to unit test Entity Framework data access with an in memory database like SqLite when the entity model is generated for another DBMS. This is not even possible in Entity Framework V2 (.NET 4.0). The generated SSDL section of the edmx file contains provider information to the specific DBMS used in production code. I.e when using SqlServer the provider will be "System.Data.SqlClient" but SQLite demands the System.Data.SQLite provider. Do you know another solution or workaround for this? Was this statement theoretical or have you managed to get it to work? I don’t think its possible to unit test Entity Framework data access with an in memory database like SqLite when the entity model is generated for another DBMS. This is not even possible in Entity Framework V2 (.NET 4.0). The generated SSDL section of the edmx file contains provider information to the specific DBMS used in production code. I.e when using SqlServer the provider will be “System.Data.SqlClient” but SQLite demands the System.Data.SQLite provider. Do you know another solution or workaround for this? Was this statement theoretical or have you managed to get it to work?

]]> By: High performance database rollback in automated tests with SQL Server | Graeme Hill on .NET development http://graemehill.ca/unit-testing-an-entity-framework-data-access-layer-part-1-just-hit-the-database/comment-page-1#comment-618 High performance database rollback in automated tests with SQL Server | Graeme Hill on .NET development Sat, 23 Jan 2010 17:17:06 +0000 http://graemehill.ca/?p=119#comment-618 [...] couple months ago I wrote this article explaining why I think it is reasonable for unit tests to hit a real database. [...] [...] couple months ago I wrote this article explaining why I think it is reasonable for unit tests to hit a real database. [...]

]]>