TDD

Unit Testing Databases with tSQLt Part 12 – Unit Testing Views

30 October 2012

In Part 11, we delved into mocking stored procedures and explored how to populate output parameters or add a row to a table when faking a procedure. In this post, we will look at views, including writing tests against the views themselves and also how to mock a view that another object under test depends […]

Read the full article →

Code Kata for SQL – Toy Story

27 August 2012

Practicing code kata is an established practice in agile shops but many kata are designed with object-oriented languages in mind and do not not always lend themselves to being reproduced in a declarative, set-based language like T-SQL.  So I have created this new kata specifically for SQL. Enjoy…

Read the full article →

Code Kata for SQL – FizzBuzz

2 August 2012

There has been some discussion recently over on the Google Groups discussion forum for tSQLt about practicing code kata in SQL.  One suggestion was to try the time-honored FizzBuzz game and I present here a slightly modified version adapted to work with a non-object oriented, set-based language like SQL.

Read the full article →

A mock too far? What is good practice for mocking database objects with tSQLt?

28 March 2012

tSQLt, the open source unit testing framework for SQL2005+ has some really great features that allow database objects to be mocked, dramatically reducing the time needed to set up reference data for each test.  But sometimes, just because you can do something doesn’t mean that you should; at least not all the time.  In this […]

Read the full article →

Unit Testing Databases with tSQLt Part 10 – testing a foreign key’s ON DELETE or ON UPDATE actions

20 March 2012

In Part 9, we looked at basic unit testing of a foreign key ensuring that basic referential integrity was properly enforced. In this post, we continue writing tests for foreign keys, delving in to cascading deletes (or not cascading as the case may be). We’re using deletes in this article but the same approach and […]

Read the full article →

Unit Testing Databases with tSQLt Part 9 – testing a FOREIGN KEY constraint

7 March 2012

In Part 8, we looked at testing string searches as part of a WHERE clause and also validating the effect of supplying multiple, cumulative search conditions. In this post, we go back to our DDL tests and explore a couple of approaches to unit testing foreign keys.

Read the full article →

Guest Post – All-Pairs Testing

1 March 2012

I am very pleased to be able to present this article written by Dennis Lloyd Jr (blog | twitter), creator of the Test Driven Databases Initiative and one of the authors of the tSQLt Unit Testing framework for SQL Server.  One of a series on applying test case heuristics to database testing, this article explores […]

Read the full article →

Unit Testing Databases with tSQLt Part 8 – testing string searches in the WHERE clause

16 February 2012

In Part 7, we looked at how to write tests to confirm that parameterised start and end dates were correctly applied in a WHERE clause. In this post we will extend that SELECT procedure further by writing more tests for the WHERE clause, specifically searching the contents of a string, and validating how default values […]

Read the full article →

Unit Testing Databases with tSQLt Part 7 – testing date ranges in a WHERE clause

13 January 2012

In Part 6, we looked at writing tests against a simple SELECT procedure checking that the correct columns were included and that results were returned in the correct order. In this post we will extend that SELECT procedure writing some tests for the WHERE clause, specifically dates and date ranges, and validating how default values […]

Read the full article →

Advanced Database Unit Testing with tSQLt – Testing cross-database tables

20 December 2011

This is the first in an occassional series of articles covering more advanced ways of getting the most out of the tSQLt database unit-testing framework. One of the features of this framework I really like is the ability to fake or mock a table. FakeTable temporarily re-names the “production” table then creates an empty copy […]

Read the full article →