Test-Driven Development with Databases, what is the best way to doit?

[Sasha]

Hi everybody,

I am starting a new ASP.NET/SQL Server project and this time I want to
do it through Test-Driven Development (TDD). The problem that I ran into
is this: How do you test data access logic with a database in the
backend? I do not want to use mock objects because if the schema changes
I will miss those errors.

If you are using TDD to test data access code, please post the
description of your setup or some pointers and suggestions.

Thank you very much for your help!

Sasha

 

[Manohar Kamath]

Without Mock objects, testing the DAL is challenging. One way I would do it
is:

1. Unit test your database code separately -- using something like
T-SQLUnit.
2. Create a "baseline" database to test your DAL objects
3. Write unit-tests for your DAL objects. Make sure that after each test,
the database returns to the original state -- using TearDown.

The most challenging parts I found were if you were using identity columns,
and want to unit test object IDs.

Hope that helps, but if you find a better answer please post it to the
newsgroup.

 

[bruce barker]

look at mbunit

-- bruce (sqlwork.com)

| Hi everybody,
|
| I am starting a new ASP.NET/SQL Server project and this time I want to
| do it through Test-Driven Development (TDD). The problem that I ran into
| is this: How do you test data access logic with a database in the
| backend? I do not want to use mock objects because if the schema changes
| I will miss those errors.
|
| If you are using TDD to test data access code, please post the
| description of your setup or some pointers and suggestions.
|
| Thank you very much for your help!
|
| Sasha

 

[Scott Allen]

Hi Sasha:

Two thoughts to consider:

Depending on your design you could use an O/R mapper or code
generation tool to spit out code. There are advantages and
disadvantages to this approach, of course, but one of the advantages
is you'll have compile errors if the upper layer code is not keeping
up with the schema changes.

Unit testing code that needs access to the database can be tricky,
using mock objects doesn't solve all the problems of course but it can
remove some dependencies and make testing easier. One approach I've
seen used is to test against the real db, but wrap your test methods
with enterprise transactions, there is a discussion here:
http://weblogs.asp.net/rosherove/articles/dbunittesting.aspx