The document discusses challenges with testing SQL code and introduces tSQLt, an open source framework for unit testing Transact-SQL code. tSQLt allows writing unit tests in T-SQL, runs tests in isolated transactions, and provides tools to isolate dependencies like faking tables and spying on stored procedures. The document demonstrates how to install tSQLt and use it to test functions and stored procedures. It also outlines some limitations of tSQLt and provides further reading on the topic.

1. T-SQL Unit Testing?
Agenda
This Is Ridiculous: The Challenges of DB Unit Testing
There Is Hope: The tSQLt Approach
The Big Picture
Digging Deeper
Behind The Wall
Isolating Dependencies
Assertions & Expectations
What Can Go Wrong
Limitations
Show Time
That Was Great: Q&A
Further Reading
It Can Be Done!

2. This Is Ridiculous
Why databases are hard to test:
Too much work to create test schemas and data
Too much work to arrange test scenarios & cleanup
SQL is not Object Oriented (No Polymorphism)
How do you create mocks, fakes or spies?
Too much work to make assertions
Inconvenient switching between tools

3. There is Hope!
tSQLt is a free, open source database unit
testing framework for Microsoft SQL Server:
• Unit Tests are written in T-SQL
• Tests automatically run within transactions – this keeps tests
independent and reduces any cleanup work you need
• Tests can be grouped together within a schema – allowing you to
organize your tests and use common setup methods
• Output can be generated in plain text or XML – making it easier to
integrate with a continuous integration tool
• Provides the ability to fake tables and views, and to create stored
procedure spies – allowing you to isolate the code which you are
testing

4. The Big Picture
EXEC tSQLt.NewTestClass 'testGroupName'
GO
CREATE PROCEDURE testGroupName.SetUp
AS
BEGIN …
END
GO
CREATE PROCEDURE testGroupName.[Test 01 - Description]
AS
BEGIN …
END
GO
CREATE PROCEDURE testGroupName.[Test 02 - Description]
AS
BEGIN …
END
GO
…
EXEC tSQLt.Run 'testGroupName'
The fixture Set Up is a stored
procedure that runs before each test
and it is useful to set up common
data and scenarios between tests
Unit Tests are Stored Procedures.
Each test runs as an independent
transaction.
Runs all the tests in the class.
To run all the tests in the database
you can use:
tSQLt.RunAll
The class declaration is
used to defined a
schema for a group of
related tests meant to
run together

5. Digging Deeper
The basic flow of a tSQLt unit test looks and
feels just like a regular OOP unit test
Arrange
Act
Assert

6. Behind The Wall
Every time we run test, under the hood tSQLt
performs the following steps:
Start a new transaction X
Run the stored procedure named “Setup”
if present within the class (schema) of the test
Run the test stored procedure
Rollback transaction X
This ensures isolation and saves time for setup and cleanup!

7. Isolating
Dependencies
Isolate data and contraints:
tSQLt.FakeTable
@TableName
Creates a copy of the original table without contraints
Isolate from stored procedure and function dependencies:
tSQLt.SpyProcedure
@ProcedureName denotes the stored procedure to isolate from
@CommandToExecute will be executed in place of the stored procedure
Table created to log when isolated procedure is called
@ProcedureName_SpyProcedureLog - Records the parameters passed
tSQLt.FakeFunction
@FunctionName denotes the function to isolate from
@FakeFunctionName will be executed in place of the original function

8. Assertions &
Expectations
tSQLt.AssertEqualsTable
@Expected denotes a table with the expected results
@Actual denotes a table with the actual results
tSQLt.AssertResultSetsHaveSameMetaData
@Expected denotes a table with the expected metadata
@Actual denotes a table with the actual metadata
tSQLt.AssertEmptyTable
@TableName expected to be empty
tSQLt.AssertEquals / tSQLt.AssertNotEquals
@Expected value
@Actual value
tSQLt.ExpectException / tSQLt. ExpectNoException
Used to verify raised exception or try/catch blocks

9. What Can
Go Wrong
Database ownership issue
T-SQL current date and time functions
Some data types are not supported in assertions
(E.g. text, blob)
Functions and Views with Schemabinding
Insert Into Exec

10. Limitations
No time measurement
No inconclusive status for tests
Only one setup routine can be written per schema
No way to disable a test temporarily
No “SpyFunction” tool
No straight cross database support
Empty tests pass by default
No Data driven tests
No free test plugin for SQL Server Management Studio

11. Show Time
I will now demonstrate how to:
Install tSQLt
Unit test a function
Unit test a stored procedure with dependencies

12. That Was Great!
Questions?
Comments?
Feedback?
Here Are My Contacts:
Email
giovanni.scerra@afsi.com
LinkedIn
http://www.linkedin.com/pub/giovanni-scerra/10/940/348

13. Further
Reading
tSQLt Tutorial
http://tsqlt.org/user-guide/tsqlt-tutorial/
Ten Things I Wish I’d Known When I Started Using tSQLt and SQL Test
https://www.simple-talk.com/sql/sql-tools/ten-things-i-wish-i%E2%80%99d-known-when-i-started-using-tsqlt-and-sql-test/
Test Driven Database Development with tSQLt
http://datacentricity.net/tsqlt/
Video Training (req. subscription): Unit Testing T-SQL Code with tSQLt
http://pluralsight.com/training/Courses/TableOfContents/unit-testing-t-sql-tsqlt
…and keep an eye on the upcoming book:
Database Unit Testing for SQL Server Using tSQLt
http://www.amazon.com/Database-Testing-Server-Robert-Martin/dp/013356432