looks interesting, but seems like a lot of overkill for
what could be as simple as attach / detach of database
files stored in source control. here's our formula:
MDF / LDF files stored in Subversion, along with schema
scripts, stored proc / function files, etc...
revert svn working copy (in case of failure below)
attach database
build database - run schema/procs/etc...
run tests
detach database
revert svn working copy
I have setup-database and teardown-database targets in
NAnt that perform the required functionality. (plus a
wrapper reset-database target for devs to run locally
when the codeline changes) Attach / detach are extremely
fast operations, coupled with the svn revert - been very
happy with the results.
If your database is SQL Server 2005
you can do the same with two lines of TSQL
-- Create the Snapshot
CREATE DATABASE ON
( NAME = , FILENAME = 'PathAndFileName ')
AS SNAPSHOT OF
-- and later restore the DB
RESTORE DATABASE from
DATABASE_SNAPSHOT = 'SnapshotName;
The nice thing about SQL 2005 snapshots is that the
snapshot creation is instantaneous (SQL uses copy on
write to fill the snapshot with data, so it just
includes the diff. from the original database as you
commit changes)
Arnon
There are certainly other ways to accomplish this. What
makes dataFresh stand out is speed and the minimal
amount of disk IO required for the refresh task. We use
standard features of sql to track what tables are being
modified and our refresh command only refreshes those
tables. dataFresh was built out of necessity -- we have
over 3,000 unit tests. We used to use a strategy that
dropped the entire database and reran the setup data
script when ever a change was detected. This could take
anywhere from 2 - 4 seconds. This time adds up quickly!
On a typical database write test, dataFresh runs in less
than a second. By integrating dataFresh alone we reduced
our build time from two hours to just under one.
Ian:
True - It's not realy a "unit test" if you do DB work in
there. It's an Integration test if anything. The problem
is you are using the unit test framework to accomplish
it so the lines feels a bit blurry.
I don't consider it a "smell" really. I think DB unoit
testing (integration testing really) is essential for
testing you data layer along with teh database because
you need to make sure it works well with the database.
Mocking the DB isn't realistic IMHO as it still leaves
you with bugs you don't know about on the DB which you
only find out in integration (unless you use something
like SQL unit which is pretty hard to use right now).
You can read the article I'm pointing to find out more
about my view on this, or you can download the first
chapter of my upcoming book "The art of unit testing"
fomr here:
http://the.artofunittesting.com which talks about what
is the difference between unit and integration tests,
among other things.
Roy.
Roy:
Great I think we are on the same page on integration
tests. I think its just important to try and point out
this difference as a lot of advice .NET developers in
this area talks about how to talk to the DB, less how
not to.