Option to exclude tSQLt dependencies?

mfearby

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

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

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

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

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

@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

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

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

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

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.