Named parameters with default values can help unit tests

Introduction I find myself using default values much more in unit tests than in production code.  That is, I do it more often, and use more parameters with defaults per method.  This isn't because default values are bad, but they are often particularly useful when setting data up for unit tests.  It makes the tests … Continue reading Named parameters with default values can help unit tests

Automated testing of a website: Dealing with the database

This article proposes an approach to handling the fine-grained parts of the database parts of an automated system test of something like a website.  You would need other things for the remaining jobs: To orchestrate the test, something like SpecFlow; To interact with the website, something like Selenium; To do the bulk updates to the … Continue reading Automated testing of a website: Dealing with the database

Practical considerations with tSQLt tests

This is the third article in a series on tSQLt: Introduction Anatomy of a test Practical considerations Dealing with transactions Getting organised One stored procedure under test is likely to need several stored procedures to test it properly.  This means that the number of stored procedures in your database will increase greatly.  (This is one … Continue reading Practical considerations with tSQLt tests

Introduction to unit testing SQL Server stored procedures with tSQLt

This article is the first in a short series on tSQLt: Introduction Anatomy of a tSQLt test Practical considerations Dealing with transactions Introduction This is the introduction to the introduction!  tSQLt lets you unit test stored procedures (including functions) on SQL Server.  For why unit testing is a good idea, see my article on unit … Continue reading Introduction to unit testing SQL Server stored procedures with tSQLt