The question of where to install tSQLt is probably the most common question I get when I talk about unit testing T-SQL, so much so that I thought that it would be a good topic for a blog. I mention tSQLt in the title, but this covers all unit test code for T-SQL. So to be more specific: Where do you install unit tests and unit tests frameworks for SQL Server, which databases should have that code in them?

So Visual Studio 2017 has been released a while and I had created a version of the test adapter (which lets you run tSQLt tests from within Visual Studio with SSDT, ReadyRoll or just plan sql scripts using the test window but I held off on pushing it to the marketplace as it didn’t work with Visual Studio 2015. I spent quite a lot of time trying to work out how to build a single vsix that worked with VS 2015 and 2017 and in the end gave up and now there are two versions, one for 2015 and one for 2017 - I am not putting any fixes into the 2015 version so I would upgrade to 2017 if you want any updates.

A free email course on how to use tSQLt including the technical aspects of writing unit tests AND the art of writing repeatable, using unit tests for even the most complicated T-SQL code UPDATE: I thought that if I got a certain number by October 1st I would run the course but in two days I had three times the number of people subscribe than my initial target so I have closed the first course, sign up if you want to join the waitlist or the next course!

I saw on slack recently a question about how the ssis file enumeraror orders (or more specifically doesn’t order) files. I have been thinking about ssis quite a lot lately and whil I am in no hurry to start using it day to day it is quite an interesting tool. So anyway, I saw this question that went like: “does anyone know in what order files are processed in ‘Foreach File Enumerator’?

K-SSIS-ed - View any property or script in SSIS with a single click A cross platform re-imagined IDE and SSIS package viewer with one goal to allow a developer to get to any property, including a c# or vb.net script within a single click and one second. For support, please raise an issue: https://github.com/GoEddie/K-SSIS-ed-docs Releases: https://github.com/GoEddie/K-SSIS-ed-docs/releases

SQL Cover is a tool to measure code coverage in T-SQL. This will tell you how much of your database code your unit tests are exercising. You can read more about it: https://the.agilesql.club/blogs/Ed-Elliott/2016-04-08/SQLCover-Code-Coverage-For-SQL-Server-T-SQL You can get the source code from: https://github.com/GoEddie/SQLCover You can download it from: https://github.com/GoEddie/SQLCover/releases/ For help feel free to ping me. Articles / Posts about SQL Cover: https://www.red-gate.com/blog/building/sql-cover https://documentation.red-gate.com/display/SR1/Using+SQL+Cover+with+SQL+Release+PowerShell+cmdlets http://www.jankowskimichal.pl/en/2016/09/sql-unit-tests-coverage-report/?utm_campaign=shareaholic&utm_medium=twitter&utm_source=socialnetwork Redgate: Redgate kindly sponsored the initial version of SQLCover and I am most greatful to David Atkinson who really helped to shape what we have ended up with.

What is the SSDT Dev Pack It is basically a collection of tools that I find make developing in for SQL Server in SSDT better or easier. I will never have the time on my own to do as much for t-sql that resharper does for t-sql but this is a start and maybe someone will invest in tools for t-sql developers at some point :) The general idea is that if I want to do something and can make it re-usable then I will add it here.

DevOps isn’t running SQL Server in a container and pushing code to it from Jenkins When we talk about DevOps we envision that we have the ability to check-in code, spin up a new environment, deploy, test and push that code to production and be in the pub at 4. We know that by having the right tooling in place we can make releases more reliable and more frequent enabling us to deploy the changes that the business want when they want them rather than every x days/weeks/months/years/decades.

Every now and then I come across this error in SSDT, normally when trying to publish and the odd thing is that the description never matches the actual cause (if you desperate for the cause it is because you can’t connect). The thing I like about the description is the way it tries to tell you what is wrong and what server you are connecting to but it fails at both and instead tells you about an unrelated error and a database name instead of a server name.

I have upgraded the ssdt dev pack to support visual studio 2017 and fixed a couple of minor annoyances and have started to think about how to improve it going forward. The first feature of sorts is the ability to clear the connection used by the quick deployer without having to restart visual studio. Secondly I am pretty convinced that the main thing people use it for is the quick deploy, the tSQLt test builder and I use the keyword formatters so I have moved everything else to underneath a menu item saying “deprecated” - if anyone really wants one of those features then let me know and I will keep it but I will likely remove them at some point.