Unit Testing SQL Server
2 likes1,221 views
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.
![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](https://image.slidesharecdn.com/1e141572-6442-4e8a-8816-dd6f4b907020-150118122213-conversion-gate02/85/Unit-Testing-SQL-Server-4-320.jpg)
Unit Testing SQL Server
- 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 [email protected] 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