Preferred Method of Disabling SQLCop Tests
There are a few SQLCop tests that aren't relevant to our local or test environments.
What is the preferred method for disabling these SQLCop tests? Just delete them? Add a RETURN statement in the proc?
My preference is to *not* delete the stored procedures, because I'm sure they'll pop up again if I ever need to reinstall/update the tSQLt framework on the database. I also don't want to go through the headache of deleting them every time I install the framework on another database.
It would be nice to specify a list of tests to exclude when you run tSQLt.RunAll so you could just update your build scripts and you'd at least have some documentation on what you've decided to ignore.
What is the preferred method for disabling these SQLCop tests? Just delete them? Add a RETURN statement in the proc?
My preference is to *not* delete the stored procedures, because I'm sure they'll pop up again if I ever need to reinstall/update the tSQLt framework on the database. I also don't want to go through the headache of deleting them every time I install the framework on another database.
It would be nice to specify a list of tests to exclude when you run tSQLt.RunAll so you could just update your build scripts and you'd at least have some documentation on what you've decided to ignore.
Comments
Unfortunately, there's no direct way to disable the SQL Cop tests. This would be a good feature request for the tool, and here's the forum for you to do so: http://sqltest.uservoice.com/forums/140 ... test-forum
There is a manual workaround that you can do in the meantime. You can export a copy of the test from SSMS and save the script, and then re-add as needed.
Best,
David
Red Gate Product Support