Option to exclude tSQLt dependencies?

• 
  Hi,
  One option that may help is to ignore the tSQLt objects. SQL Source Control has an option to exclude these, in amongst the Compare Engine settings. You can amend them as described here - look for one called IgnoreTSQLT

  James B July 11, 2014 10:59

  - 0 +
• 
  Thanks for reply, I didn't know about those settings (they're well hidden!).
  
  Unfortunately setting IgnoreTSQLT to True excludes my test cases, and not just the tSQLt objects that my test cases depend on. It seems silly to be committing those to source control.
  
  So I guess I should just commit all the tSQLt dependencies and move on? It would be nice if you had an IgnoreTSQLTDependencies option.

  mfearby July 13, 2014 21:24

  - 0 +
• 
  Ah, yes, it probably isn't granular enough to help there. The other option you could look at is the slightly-more discoverable filtering, it works similarly to in SQL Compare: Filters

  James B July 14, 2014 02:31

  - 0 +
• 

  mfearby wrote:

  
  So I guess I should just commit all the tSQLt dependencies and move on?.

  
  Yes, that would be simplest. When you need to deploy from SQL Compare using SQL Source Control as a data source, and if you don't want to include tSQLt or your tests, you can use the SQL Compare option to exclude them.

  David Atkinson July 14, 2014 11:36

  - 0 +
• 
  mfearby - Our shop commits tSQLt objects and developer written tests with our source control. We apply the filters when deploying to non-testing environments, so they won't eventually make it to production.
  
  You need those objects (the tSQLt objects as well as your own) there if you want to run the unit tests, so it makes sense that you would always want one with the other.

  JackAce July 14, 2014 17:46

  - 0 +
• 
  I came at it from the point of view that tSQLt is effectively a third-party library that I should always be getting from the supplier, and not committing to source control. I regarded it as a bit like committing some third-party DLLs, but perhaps it's not the right analogy.
  
  I'll just commit them, then. Thanks.

  mfearby July 14, 2014 18:54

  - 0 +
• 
  Another benefit of committing to source control is that if you're not the only developer on the project, it just takes one developer to update tSQLt to the latest release, and all other developers get that at no more effort than clicking on "get latest".

  David Atkinson July 14, 2014 20:05

  - 0 +
• 
  Well, that's strange. Now that I've come to terms with committing tSQLt dependencies, it didn't offer to do so today, and I've got IgnoreTSQLT set to false, as well. I'll keep an eye on it
  
  Thanks David. I am currently the only developer, but that might change one day, I guess.

  mfearby July 14, 2014 20:14

  - 0 +
• 
  It seems that the filters that I added a few days ago have decided to take effect:
  
  Schema:
  Exclude if ( schema name beings with 'tSQLt' ) OR (object name begins with 'SQLCop' )
  
  Stored Procedure:
  Exclude if ( schema name beings with 'tSQLt' )
  
  
  After removing them, they're appearing as things to commit in their own right, not as dependencies. But my filter didn't seem to prevent them being offered as dependencies until today, where I couldn't get it to nag me about dependencies if my life depended on it. Very strange.

  mfearby July 14, 2014 21:07

  - 0 +

Add comment

Please sign in to leave a comment.