Improve Your Database Unit Testing Skills and Win Free Stuff

As the SQL Developer community grows to embrace the benefits of test-driven development for databases, so the importance of learning to do it properly increases. One way of learning effective TDD is by the use of code kata – short practice sessions that encourage test-first development in baby steps. Thanks to the guys at Red-Gate, I have a limited number of licences for SQL Test to give away free – just for practicing a bit of TDD and telling me about it.

All you need to do is to try out a code kata using T-SQL, either on your own or with a colleague, then tell me about it. This could be just a paragraph or two in a comment on this post or an entry on your own blog which links back to this post. Write about which kata you chose and why, how you wrote and tested the code and what you gained from the experience. I will pick the five best write-ups (from a mixture of blogs and comments) and send each of those contributors a single-user licence key for Red-Gate’s SQL Test. You can use any test framework as long as your tests are written in T-SQL.

You could even publish your experiences as an article on Simple-Talk. They pay for original content and provided you include a link back to this post, you could still win a SQL Test licence. Although you’ll have to be quick to allow for the editorial lead time between submitting an article and it being published.

SQL Test

Regular readers will be aware of my enthusiasm for tSQLt the open-source unit testing framework for SQL2005+. I’m not the only one that rates this library since Red-Gate liked it so much they have used it as the platform on which they built SQL Test. This graphical test manager is a plug-in for SQL Server Management Studio, originally developed during one of Red-Gate’s famous down-tools weeks and now an established part of their SQL Developer product suite.

What is a Code Kata?

According to Wikipedia, “kata is a Japanese word describing detailed choreographed patterns of movements practised either solo or in pairs… Kata originally were teaching/training methods by which successful combat techniques were preserved and passed on“. I believe the term “code kata” was first coined by Dave Thomas (blog) in his book The Pragmatic Programmer who writes:

Code Kata is an attempt to bring this element of practice to software development. A kata is an exercise in karate where you repeat a form many, many times, making little improvements in each. The intent behind code kata is similar. Each is a short exercise (perhaps 30 minutes to an hour long). Some involve programming, and can be coded in many different ways. Some are open ended, and involve thinking about the issues behind programming. These are unlikely to have a single correct answer.

What this means in test-driven programming terms is a simple, often deceptively so, logic problem which developers attempt to solve using strict test first development. People will often pair program on this task redoing the same exercise every day for a week or more pairing with different developers each day and trying to improve on the solution at each attempt. Typically, they will spend no more than 30 or 60 minutes per day on these exercises.

This practice is intended to help programmers learn to write code using TDD properly – not always a luxury we have in the real world. The aim is to write code in small baby steps each supported by tests to gain an understanding of the test-first paradigm. The code kata is a safe environment in which to experiment with ideas and best practice without any real consequences or deadlines. Peter Provost has a nice write-up on the importance of kata in learning effective TDD.

Why is SQL Different?

Although often language-neutral, many kata are written with object oriented languages in mind. Looking at how some online examples are developed and refactored, more complex kata would struggle to work in T-SQL in their current form. But whilst we don’t have many of the standard OO features in SQL Server programming, we do have a set-based language along with features like DRI, views and table-valued functions. The nature of the language will lead to different solutions and such features present different opportunities for refactoring.