Best Practices when committing tSQLt test suite

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?
Tagged:

Answers

  • Jessica RJessica R Posts: 1,319 Rose Gold 4
    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! 

    Jessica Ramos | Product Support Engineer | Redgate Software

    Have you visited our Help Center?


Sign In or Register to comment.