Skip to content

tSQLt 101

In the previous post on unit testing, I tried to demonstrate how a bug can be created in a pretty innocuous fashion.  Unit testing is common in most development platforms, but as always, SQL has to be different.  SQL has state – mostly because of the data within the database.  If you have some C# code, and you want to completely re-write it, go ahead.  As long as the inputs, outputs, and other behaviors are the same, you should be fine.  Not so with SQL, which makes unit testing a little trickier.

There are several unit testing frameworks out there.  The one I have been using is tSQLt.  Although it is powerful, the documentation left me lost. In a series of articles, I would like to demonstrate how to set up tSQLt, and how to set up a basic test.  I will then go into some more details about building a test framework of many tests, and ways to automate the testing, hopefully elaborating on the documentation as I go along.Read More »tSQLt 101

Why Haven’t You Attended a SQL Saturday? T-SQL Tuesday #41

TSQL2sDay150x150I have been blogging a little bit here for a few months.  If you take the time to wander around, you will find that I am still searching for my voice.  This month’s TSQLTuesday topic, as proposed by Bob Pusateri is “Presenting and Loving It!”  I have not presented outside of my own company, but I thought I could add my thoughts on the topic within the context of SQL Saturday.  Part of this is based on my gratitude for the fine people that put on these events – the organizers and speakers.  Specifically, I want to know why any SQL professional would pass up on a SQL Saturday.

This past Saturday, April 6th, there were three SQL Saturday events in the United States, and one more in Holland. I went to the one in Boston. It was my second in a month, and third in the last 7 months. These are wonderful events for so many reasons. If you really care about SQL, either from a callous “it’s my job” point of view, or hopefully more enthusiastic posture, you really should try and take advantage of a SQL Saturday event near you. Here are a few reasons:Read More »Why Haven’t You Attended a SQL Saturday? T-SQL Tuesday #41

SQL Unit Testing 101

So, what is Unit Testing? According to Wikipedia (http://en.wikipedia.org/wiki/Unit_testing)

In computer programming, unit testing is a method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine if they are fit for use. Intuitively, one can view a unit as the smallest testable part of an application. In procedural programming a unit could be an entire module but is more commonly an individual function or procedure. In object-oriented programming a unit is often an entire interface, such as a class, but could be an individual method.  Unit tests are created by programmers or occasionally by white box testers during the development process.

Quite a mouthful there.  In my experience, a unit test is a small piece of isolated code that gets tested to make sure that it meets the requirements specified for it.  For example, let’s say you have a function that multiplies a number by two. Given an input of 12, you expect an output of 24.Read More »SQL Unit Testing 101

Building the first SQL Server in the Lab – Part 3

Now we are getting to some good stuff.  Before we install, we need some service accounts.  If you are going to have a lot of SQL servers to manage, coming up with a consistent account naming convention will make you life much easier.  My domain is named timharkin, so for my SQL server named SQL01, I will create the following accounts:

timharkin\SQL01Service

timharkin\SQL01Agent

timharkin\SQL01SSIS

I will make sure that the accounts have no expiration.Read More »Building the first SQL Server in the Lab – Part 3