SQL Server Team-based Development - Red Gate Software

Testing tables, views, and UDFs
157
Chapter 5: Testing Databases
Tables, views, and UDFs are all tested in the same manner, namely by directly executing
T-SQL queries against them. In each case, we are testing the validity of the returned data
so, in that sense, this is pure black-box testing.
We're basically testing that any changes made to these database objects, such as adding or
removing joins to views, or changing some business logic in a UDF, haven't changed the
expected result.
These tests should be run under the same isolation level as that which the application will
use, and we need to perform both read and write tests against these objects, since they
can be used to modify data, as well as read it. Scalar UDFs fall into the read-test category,
since we can't insert data through a scalar UDF.
Included in the write-testing of tables, is the testing of triggers. A trigger cannot be fired
directly; it is executed as part of a table modification procedure. Therefore, our write tests
on the tables must consider the effects of any triggers that may be fired, and may modify
other tables as a result. Each of these "secondary" tables is added to the unit that we must
test. Overuse of triggers can greatly widen our testing scope and make the tests huge,
bulky, and impractical.
Listing 5-6 shows three test methods; a table read test, along with write tests for a table
and a view, as shown here.
• Table_single_line_read_from_Person_Address method – returns the first
row from the Person.Address table, ordered by AddressId column, and checks its
value against our known values.
• Table_single_line_insert_into_Person_Address method – inserts a single
new row into the Person.Address table and tests if the inserted values match our
known values. For example, if we had a trigger on the Person.Address table that