Thanks to Redgate for supporting this open source project

This is a code coverage tool for SQL Server 2008+, it was designed to be generic to work with any build server and tests but includes specific filters to mean that it is well suited to running tSQLt tests using the Redgate DLM Automation Suite.

Navigation:

• Installation
• Usage
  • 1. Redgate DLM Automation Suite
  • 2. Cover T-SQL Script
  • 3. Cover anything else
• A final word...
• License

You will either need to build the project and grab the output SQLCover.dll or you can download the pre-built binary from: http://the.agilesql.club/SQLCover/download.php

There are three basic ways to use it:

If you have the DLM automation suite then create a nuget package of your database, deploy the project to a test database and then use the example powershell script (https://github.com/GoEddie/SQLCover/blob/master/example/SQLCover.ps1 and included in the download above):

Get-CoverRedgateCITest "SQLCover-path.dll" "server=servername;integrated security=sspi;" "nuget-package-path.nupkg" "servername" "database-name"

To create the nupkg of your database you can use sqlci.exe or create a zip of your .sql files see: https://www.simple-talk.com/blogs/2014/12/18/using\_sql\_release\_with\_powershell/

The Get-CoverRedgateCITest will return an array with two objects in, the first object is a:

RedGate.SQLRelease.Compare.SchemaTesting.TestResults

The second object is a:

SQLCover.CoverageResult

This has two public properties:

public long StatementCount;
public long CoveredStatementCount;

It also has two public methods:

public string Html()

This creates a basic html report to view the code coverage, highlighting the lines of code in the database which have been covered and:

public string OpenCoverXml()

which creates an xml file in the OpenCoverageXml format which can be converted into a very pretty looking report using reportgenerator: https://github.com/danielpalme/ReportGenerator

For a complete example see:

$results = Get-CoverRedgateCITest "path\to\SQLCover.dll" "server=.;integrated security=sspi;initial catalog=tSQLt_Example" "tSQLt_Example"
    Export-DlmDatabaseTestResults $results[0] -OutputFile c:\temp\junit.xml -force
    Export-OpenXml $results[1] "c:\output\path\for\xml\results"
    Start-ReportGenerator "c:\output\path\for\xml\results" "c:\path\to\reportgenerator.exe"

If you have a script you want to cover then you can call:

Get-CoverTSql  "SQLCover-path.dll" "server=servername;integrated security=sspi;"  "database-name" "exec tSQLt.RunAll

This will give you a CoverageResults where you can either examine the amount of statement covered or output the full html or xml report.  

If you want to have more control over what is covered, you can start a coverage session, run whatever queries you like from whatever application and then stop the coverage trace and get the CoverageResults which you can then use to generate a report.

$coverage = new-object SQLCover.CodeCoverage($connectionString, $database)
$coverage.Start()
#DO SOMETHING HERE
$coverageResults = $coverage.Stop()

When we target local sql instances we delete the trace files but when targetting remote instances we are unable to delete the files as we do not (or potentially) do not have access. If this is the case keep an eye on the log directory and remove old "SQLCover-Trace-.xel" and "SQLCover-Trace-.xem" files.

Apache 2.0

To run the integration tests, create a sql instance or using the ./src/SQLCover/test/CreateDockerDbInstance.ps1 script to create a docker version of sql. Then run ./src/SQLCover/test/deployLocal.ps1 (if you use your own instance deploy the DatabaseProject ssdt project to the instance). The connection string that the integration tests use is Server=tcp:docker-instance-ip;uid=sa;pwd=Psgsgsfsfs!!!!!;initial catalog=DatabaseProject where docker-instance-ip is the ip address of the container created by ./src/SQLCover/test/CreateDockerDbInstance.ps1. If you want the tests to use a different connection string, in the \src\SQLCover\DatabaseProject\bin\Debug folder put a ConnectionString.user.config which is a text file with one line that is the connection string that you want to use. The unit tests need no connection string.