Part 2 of this series covers how to run tSQLt unit tests from within the Visual Studio IDE.
(First of all, a caveat: You need to be using either Visual Studio 2015 or 2017.)
For tSQLt unit tests, you'll need the tSQLt Test Adapter, an open-source test adapter that (together with a runsettings file containing a SQL connection string to your test SQL server) runs your tSQLt unit tests for you and reports on the outcome.
If you're using a custom test adapter, and building your solution in VSTS, you'll need to make the custom test adapter available to the test runner on your build server.
So just how do I run my tSQLt Unit Tests within Visual Studio?
A quick background on test adapters in Visual Studio: VS comes with an extensible unit testing framework. A number of developers have written test adapters which work with this unit test framework, such as NUnit, xUnit, Chutzpah, and many others.
For tSQLt unit tests, you'll need the tSQLt Test Adapter, an open-source test adapter written by Ed Elliott. (If you're a developer who uses Microsoft SQL, his blog is invaluable; you can find it at https://the.agilesql.club/Blogs/Ed-Elliott/) that (together with a runsettings file containing a SQL connection string to your test SQL server) runs your tSQLt unit tests for you and reports on the outcome.
The tSQLt Test Adapter, together with a runsettings file containing a SQL connection string to your test SQL server, runs your tSQLt unit tests for you and reports on the outcome. This extension is available for both VS2015 and VS2017; simply install the version you need from the menu at Tools -> Extensions and Updates, search on 'tSQLt' and there it is:
If you're using Visual Studio 2015, the extension is simply 'tSQLt Test Adapter':
After you have the extension installed, you still need to let VS know what server to run the tests on. (Remember that these unit tests are written in T-SQL....and need to get executed on a SQL server somewhere.) This can be done by creating a runsettings file. This is simply an XML file with a database connection string, which will be used by the test adapter when the tests are run.
Here's what my runsettings file looks like. I've also added an "IncludePath" parameter to let the tSQLt Test Adapter know that it only needs to search for unit tests in folders named "UnitTests".
I've named this runsettings file "localhost" because, well, this is the one I want to run on my local system while I'm testing the bits of code I've just written. (I've also got a separate runsettings file for the build server, and that gets used during the build process.) All of my runsettings files are included in the solution.
To let the test process know which runsettings file to use, go to Select Test Settings File in under the Test Menu and pick the file you just created:
Now all that's left to do is open the Test Explorer Window, hit 'Run All', and check the output:
And there are your tests!
In the next article I'll discuss how to set up your VSTS build process to use the tSQLt test adapter extension to run your tSQLt unit tests from an automated build.
This is a continuation of an earlier article in this series. You can find Part 1 - guidance on setting up your SSDT project structure - here.