Source control tSQLt procs and tables but keep them from being deployed to higher environments
gbritton
Posts: 17 Bronze 1
We're starting to use tSQLt for unit testing. Next, we want to source control those tests. The big question is, when we want to deploy changes to higher-than-dev environments, how can we simply keep those tests from being considered? Our challenge is that each test class is its own database schema. We're just getting started and are using this convention:
Stored Procedure to be tested: schema1.storedprocedure
tSQLt class: schema1_storedprocedure
With that convention, when it is time to deploy changes to higher environments (e.g. using SQL Compare), both the tSQLt schema and the class schema schema1_storedprocedure are offered for deployment. We don't want the framework or the tests promoted.
What are some strategies to keep unit tests from polluting higher environments?
Stored Procedure to be tested: schema1.storedprocedure
tSQLt class: schema1_storedprocedure
With that convention, when it is time to deploy changes to higher environments (e.g. using SQL Compare), both the tSQLt schema and the class schema schema1_storedprocedure are offered for deployment. We don't want the framework or the tests promoted.
What are some strategies to keep unit tests from polluting higher environments?
Tagged:
Best Answer
-
PlantBasedSQL
Posts: 187 Gold 4
Hi @gbritton - thank you for your question! When deploying from your VCS with SQL Compare Pro there are built-in project options (before you carry out the comparison) in SQL Compare to ignore the 'tSQLt framework and tests'. Let me know if this helps!
https://documentation.red-gate.com/sc13/setting-up-the-comparison/setting-project-options
