Best Practices when committing tSQLt test suite

ScottLoney

We've recently been learning more about the tSQLt test code.  We've written a number of test cases and we've been happy with the results.  The next step for us is to commit our test suite, but we're not sure what best practices are.

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?

Jessica R

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!