0

My company has recently started using tSQLt to test our codebase. We've built a few good test suites and now we're trying to figure out the best way to commit them.

We're using an SQL server with Redgate to commit our live code to a github.com repository.

One option we thought of would be to commit the tSQLt scripts alongside our live code in the same repository, but we feel this isn't the best choice. It would mean our test code would/could be uploaded to the live servers.

Another option would be to commit the tSQLt scripts to a second repository. This solution keeps the code separate but has more overhead. When our developers want to run test cases they would have to first pull the live code onto their dev databases, then pull the tSQLt code onto their databases. Also, when developer create new live code and make the corresponding tSQLt tests, they have remember to push the live code and test code to the appropriate repository. Seems like a lot of extra work.

Has anyone run into this issue? How did you resolve it? Are there best practices when committing test code?

Thanks!!

Scott Loney
  • 1

1 Answers1

3

The best practice is to keep tests and code in the same repository. Have the CI pipeline create an artifact for the code (without the tests) and a separate artifact for the tests. Then deploy both to the CI environment together with tSQLt itself and run the tests. If the tests are passing you can send the code-artifact on to be used in down steam environments.

Sebastian Meine
  • 11,260
  • 29
  • 41
  • We dont' have a CI pipeline yet - we do updates manually by applying a github live branch. Would using a git ignore to remove tests and tSQLt install sps etc on the live branch be a good idea? – Jens Frandsen May 20 '21 at 23:59
  • 1
    @JensFrandsen, you'll get more answers, If you ask a new question here. Few people check back on old questions. --- You should handle the separation of tests and code in the build, not with git hacks. --- Also, the tests are an important part of your product, even though you're not deploying them to production. As such, they definitely should be part of your main branch in github. – Sebastian Meine May 21 '21 at 03:25