How can we help you today? How can we help you today?

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?
tech
0

Comments

2 comments

Sort by
  • 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! 
    Jessica R
    0
  • Kena Anna

    It's great to hear that you're making progress with tSQLt! When it comes to committing your test suite, a common best practice is to keep it in a separate repository, which helps avoid cluttering your production environment. I recently went through a similar decision-making process and even reflected on it while taking the rice purity test; sometimes, separating concerns can lead to clearer outcomes. Consider also incorporating CI/CD practices to automate your testing process, further enhancing your workflow. Good luck with your testing efforts!

    Kena Anna
    0

Add comment

Please sign in to leave a comment.