Option to exclude tSQLt dependencies?

mfearby · July 11, 2014 2:01AM

I've just started looking into SQL Test, and have included my SetUp test script in the same source control repository as the database it's supposed to test, but I don't want to check-in the 15 dependencies that are all tSQLt-related (e.g., FakeTable, Private_ValidateFakeTableParameters, etc).

Is there a way to configure SQL Source Control to never recommend the inclusion of dependencies for any stored procedure in my test schema?

James B · July 11, 2014 10:59AM

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

mfearby · July 13, 2014 9:24PM

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.

James B · July 14, 2014 2:31AM

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

David Atkinson · July 14, 2014 11:36AM

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.

JackAce · July 14, 2014 5:46PM

@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.

mfearby · July 14, 2014 6:54PM

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.

David Atkinson · July 14, 2014 8:05PM

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".

mfearby · July 14, 2014 8:14PM

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 9:07PM

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.

Option to exclude tSQLt dependencies?

Comments

Product Learning

Community Forums

Events & Friends

Simple Talk