SQL Server Team-based Development - Red Gate Software

Chapter 5: Testing Databases
A testing tool
Having set up the test lab, source control, schema management, and auto deployment,
it's time to think about how to actually write the tests. My tool of choice is NUnit (http://
www.nunit.org) which, along with similar tools such as xUnit or MBUnit, requires
the test code to be written in a .NET language such as C# or VB.NET. An alternative
approach is a unit testing tool such as TSQLUnit (http://sourceforge.net/apps/trac/
tsqlunit/), which allows tests to be written in T-SQL. When testing databases, this may
feel like a good fit, but it's a tool I've tried and now avoid, mainly because it violates my
"Don't store any unnecessary objects in SQL Server" principle.
Every extra object means more space is taken up; not just space on disk, but memory
space for associated execution plans and cached data pages. Sure, those can be flushed,
but this just means extra work for the database engine.
For these reasons, I think that tests have no place in a database and, in any event, I find
that tests written in .NET are far easier to manage and run.
A data generation tool
Testing often requires a database to be populated with known test data. It is not always
appropriate to use production data in a development environment, and manually creating
test data can be a monotonous, time-consuming task.
One solution to this problem is to use a tool such as SQL Data Generator (SDG) to help
create realistic test data. It has a simple graphical user interface that allows you to choose
the type of data you want to generate for each table and column, and it automatically
assigns a generator to each column, based on its table name, column name, data type, and
length. If the column has constraints, SDG uses these to set the generator parameters for
the column (you can change the generator used by a particular column later, if required).
140