 |
|||||||||
|
|||||||||
|
|
I had the opportunity to write an article for 4guysfromrolla - "Unit Testing the Data Access Layer".
"Unit testing is becoming very popular among .NET projects, but unit testing the Data Access Layer (DAL) still remains a common obstacle. The problem stems from the very nature of databases: they are slow, common, persistent, external, and relational. This conflicts the nature of unit tests, which should be quick, independent, and repeatable..."
You can read the entire article on the 4GFR website at:
Great article; I'll find this very useful. I liked how you explained the
two methods - RunScript and RecreateDBSchema, and then provided practical
examples.
Mark
I believe that any DataLayer must be a simple code block, that they allow
operations against DB.
That code block would not have to know on the Business Entities. Single to specialize it is to execute the operations (Store Procedures and SQL Sentences) against the engine DB (SQL, Oracle, DB2, etc.), with which this setting.
Finally, I invite to you to download the DataLayer.Primitives Public Version.
This is very cool Data Layer :)
DataLayer.Primitives - Readme!
http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=1389
Cheers,
Javier Luna
http://guydotnetxmlwebservices.blogspot.com/
Hi Tim - Very good article! We have come up with a way to snapshot the
database, track changes and then put the database back into a known state.
dataFresh is an API that integrates directly into your test framework and
will very quickly restore only those tables that were modified. Check out
my blog for the details!
