This is a fork which lets us create a properly signed SQL Cover package that can be used by our SSMS addins.
Publish the DatabaseProject database to is-2016.testnet.red-gate.com (or change the server in IntegrationTests.SQLCoverTest and then use that server) as a database named SqlCoverDatabase. Now you should be able to run all the tests.
- Launch .sln file in VS
- Restore nuget packages (sometimes this doesn't work unless done manually)
- Update version in AssemblyInfo
- Build solution
- Change version in nuspec file in nuspec folder
- Load nuspec file in Nuget Package Explorer (available from Windows Store)
- Use 'Save As...' to get a nupkg file
- Publish that nupkg file using the invocation in push.bat (updating the file name) - you may have to go and find nuget.exe from somewhere if it isn't in your path
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:
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.