2

We are using RedGate combined with SQL Test (tSQLt). In order to unit test, we install the framework on each database.

Is there a way to use the tSQLt framework in such a way where your unit tests and framework objects can reside in one central location which can then be used by multiple databases?

We are also using RedGate's SQL Source Control with TFS as our repository to track schema changes. These changes get promoted in the following environment order: Development --> Test --> Production.

Needless to say, the addition of the framework combined with the tests themselves represent large amount of new SQL objects (tables, stored procedures, etc) now in our databases. Ideally we would like these objects to reside only in Development and Test and avoid cluttering our production database. We could skip merging the tSQLt changes to Production, but then we would have unmerged changes sitting around in the Test environment's source control until the end of time.

Any thoughts on getting around this problem?

K. Akins
  • 657
  • 1
  • 7
  • 12
  • It would help to know how you are currently promoting your changes from Dev to Test to Production. Are you using a tool or automated process? – David Atkinson Apr 28 '16 at 11:00
  • Hi David, thanks for your response. We currently use TFS to manually promote changes from Dev to Test. This is done via Visual Studio in Source Control Explorer. – K. Akins May 03 '16 at 13:23
  • By "TFS" do you mean the Schema Compare tool in Visual Studio? – David Atkinson May 03 '16 at 15:15
  • Sorry for the late reply. We will use RedGate's SQL Source Control to check in our changes to TFS. Then, as we are promoting to other branches, we will find the changesets that were checked in with RedGate and merge them. – K. Akins May 29 '16 at 19:16
  • I've posted an answer below. It would be helpful if you explained how you're applying your changes to your environments from version control. – David Atkinson May 30 '16 at 14:31

3 Answers3

2

As you're using SQL Source Control to manage your database changes, checking in your tSQLt tests is the right thing to do. If you want to ensure that these don't get pushed to staging or production, you need to ensure that the tools you use to push the changes exclude the tSQLt tests. If you are using Redgate SQL Compare for this, use the option "Ignore tSQLt framework and tests". See the product documentation for a detailed explanation. If you are using a different tool or process, post a comment and I'll amend this answer.

David Atkinson
  • 5,759
  • 2
  • 28
  • 35
1

There is currently no way to install tSQLt in a separate database. I have started the process of making tSQLt database agnostic, but that is basically a complete rewrite, so it will take a while.

In the meantime, you can exclude tSQLt from SQL Source Control: https://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/4901910-faster-way-to-exclude-all-tsqlt-content

Sebastian Meine
  • 11,260
  • 29
  • 41
  • Note that the instructions on that link are out of date now. In recent versions of SQL Source Control you can change this setting on the Setup tab for the database. See here: https://documentation.red-gate.com/display/SOC4/Comparison+options – James Apr 27 '16 at 09:55
  • Thanks for your response Sebastian and James. I will look into this option as a last resort I suppose, because we are concerned about preserving change history for modified unit tests. So de-linking from source control may be what we have to do for now, even if its not ideal. – K. Akins May 03 '16 at 13:15
0

If you still want your tests in source control but don't want to promote them to the higher environments, that is the default behaviour in Redgate's DLM Automation Suite. You can either use one of the build server plugins (like TeamCity or TFS for build/test then Octopus Deploy for release) or do it all in PowerShell using SQL Release. https://documentation.red-gate.com/display/SR1/SQL+Release+documentation

If you have a license for Redgate's SQL Toolbelt, you might already be licensed for the Automation tools (this is a change to previous licensing); http://www.red-gate.com/products/sql-development/sql-toolbelt/#automation

Richard Macaskill
  • 1
  • Thanks for the response Cas, I'll look into this. I believe we are currently licensed for the SQL Developer Suite. From just glancing at RedGate's page on that product, its unclear whether or not DLM Automation is included in our bundle. – K. Akins May 03 '16 at 13:18
  • I just confirmed that DLM Automation is not included in the Developer Suite, and it's a pretty steep price for us to pay just to use this feature, however I'll check with our DBA team to see if their license is upgraded. If not, I'm assuming DLM Automation is the only way? – K. Akins May 03 '16 at 13:43