Comments
1 comment
-
Hi and thanks for your post!
With regard to tSQLt, the best practice is to commit the test suite alongside your production code and use SQL Change Automation to deploy to production.
By default, SQL Change Automation will exclude the test suite from deployments using the "Ignore tSQLt" comparison option. (More info on default comparison options used here.)
Hope that info helps!
Add comment
Please sign in to leave a comment.
On one hand we could commit the test suite alongside our production code. This seems like a bad idea - the test suite would end up on the production servers. On the other hand we could setup a second repository for the test suite, but that has it's own issues.
Is there any best practices that we should follow?