Code Coverage In SSDT

Ed Elliott continues to amaze me.  This time, he’s got a code coverage tool for T-SQL code:

If we execute this stored procedure we can monitor and show a) how many statements there are in this and also b) which statements have been called but we can’t see which branches of the case statement were actually called. If it was a compiled language like c# where we have a profiler that can alter the assembly etc then we could find out exactly what was called but I personally think knowing which statements are called is way better than having no knowledge of what level of code coverage we have.

Yet another reason to grab the SSDT Dev Pack.  By this point, I expect there to be a couple more reasons next week…

Related Posts

Excluding Checks With dbachecks

Garry Bargsley shows us how to set a config which lets us exclude particular checks when running dbachecks: While tweaking my Invoke-DbcCheck  the list of  -ExcludeCheck checks keeps growing and growing. 1 Invoke-DbcCheck -SqlInstance $Servers -ComputerName $Servers -Check $_ -ExcludeDatabase ReportServer, ReportServerTempDB -ExcludeCheck TestLastBackup, TestLastBackupVerifyOnly, LinkedServerConnection, SPN, MaintenanceSolution, SaRenamed, LastGoodCheckDb, LogShipping, InvalidDatabaseOwner -PassThru | Update-DbcPowerBiDataSource -Environment Production Sure […]

Read More

Unit Testing Spark Streaming DStreams

Anuj Saxena shows how to create unit tests for DStreams in Spark Streaming: The method ‘ testOperation ‘ takes the output of the operation performed on the ‘inputPair’ and check whether it is equal to the ‘outputPair’ and just like this, we can test our business logic. This short snippet lets you test your business logic without […]

Read More


January 2016
« Dec Feb »