Integration tests should be able to be run using in-memory SqlLite

[GoogleCodeExporter]

Although unit testing against a "live" DB should still be allowed, it would 
be great to have the option to run all integration tests using an in-memory 
SqlLite DB.

Original issue reported on code.google.com by wmccaffe...@gmail.com on 17 Nov 2008 at 6:27

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Included Files:

    App.config
    CategoryRepositorySpecs.cs
    CategoryRepositoryTestsNew.cs
    DatabaseSpecBase.cs
    DatabaseUnitTestBase.cs
    hibernate.cfg.xml
    SpecExtensions.cs
    System.Data.SQLite.dll

Installation Instructions:

    0. Starting at Rev 73 (v 0.9.72):
    1. Add DatabaseUnitTestBase.cs and DatabaseSpecBase.cs to the NHibernate directory
of the SharpArch.Data project.
    2. Rebuild the SharpArch solution.
    3. Copy the newly compiled SharpArch.Data.dll file into the NorthwindSample/Solution
Items directory, overwriting the existing file.
    4. Copy the System.Data.SQLite.dll file into the NorthwindSample/Solution Items
directory.
    5. In the Northwind.Test project, add a reference to System.Data.SQLite.dll.
    6. Add the CategoryRepositoryTestsNew.cs and CategoryRepositorySpecs.cs files to the
NorthwindData directory of the Northwind.Tests project.
    7. Add the SpecExtensions.cs, hibernate.cfg.xml, and App.config (overwriting the
existing App.config) files to the root of the Northwind.Tests project.
    8. Set the "Copy to Output Directory" property of the hibernate.cfg.xml file to
"Copy Always".
    9. Rebuild the Northwind project and run the new unit tests.

Developer Notes:

    I created two different styles of in-memory database base classes:

    The first, DatabaseUnitTestBase, is based on a more traditional style of unit testing.

    The second, DatabaseSpecBase, allows you to do a BDD style testing, and is based on
this article - http://flux88.com/TheTransitionFromTDDToBDD.aspx - by Ben 
Scheirman.
Frankly, this approach can look either lame or like overkill when all your 
testing
are things like GetAll() and GetByID(). It really shines; however, when the 
single
method your testing has several requirements that need to be tested.

    The tests in CategoryRepositorySpecs.cs rely on extension methods in the
SpecExtensions.cs file. This file is from the CodeCampServer open source 
project (see
link at the top of the file) that is run by Jeffrey Palermo. I'd love to see
something like this incorporated into the SharpArch project, although I'm not 
exactly
sure where the file should go (it requires a reference to NUnit). These 
extensions
make for great test readability, especially if you're approaching testing from 
a BDD
mindset.

    One thing about testing against in-memory databases is that you have to load your
test data before doing any testing. At first this seemed like extra work, but I 
now
find that it adds tremendous clarity and portability to your tests.

    The code I wrote works, but I'm not sure if my use of the NHibernateSession class's
methods is correct, could you do a quick code review and let me know if anything
needs changing.

Follow Up:

    If you like, I can write some unit tests for the DatabaseUnitTestBase.cs and
DatabaseSpecBase.cs.

    If you like, I can rewrite some of the existing database tests using either or both
of these new base classes.

Original comment by quizi...@gmail.com on 18 Nov 2008 at 4:33

Attachments:

• issue_20_patch.zip

[GoogleCodeExporter]

There's one thing about my solution that I don't like - Both DatabaseSpecBase
 and DatabaseUnitTestBase depend on NUnit - if you place them in the SharpArch.Data
project, then the project needs a reference to Nunit, which somehow seems out 
of place.

How about creating a new, separate SharpArch.Testing project for all of these
test-related classes (including SpecExtensions)? Conceptually it seems cleaner.

One more change: DatabaseSpecBase contains a When() method - I vote for 
changing the
name to Act(). I think it improves readability, especially when using class or
namespace names like "when_updating_a_product()" - it's a little jarring to see
"when_" and then "When". Naming it "Act()" also ties in nicely to the
Arrange/Act/Assert convention.

Original comment by quizi...@gmail.com on 21 Nov 2008 at 11:18

[GoogleCodeExporter]

I've added all of this to my local development environment and it's working 
great.  
This is terrific work!  Could you please provide unit tests for 
DatabaseUnitTestBase 
and DatabaseSpecBase?

Original comment by wmccaffe...@gmail.com on 26 Nov 2008 at 2:07

• Changed state: Started

[GoogleCodeExporter]

Thanks again for the help Lee...this was truly an awesome addition to the 
architecture!!

Original comment by wmccaffe...@gmail.com on 4 Dec 2008 at 3:16

• Changed state: Fixed