Why shouldn't I use tSQLt in production?

Question

I want to use tSQLt framework for unit testing my T-SQL queries. However documentation warns:

Note: tSQLt should never be installed in production.

In my case I have single instance of SQL Server, containing both production databases and dev databases.

Will installing tSQLt give me some problems in itself, or is the warning just because of all the locks that come with using it? I obviously plan to use one of dev databases for my work, but I am not sure there are server-wide implications that come with the framework.

Answer 1

When I say production, I’m mostly talking about the production database containing the important data. There are no performance concerns, but tSQLt does things (like renaming tables) that make it somewhat easy to shoot yourself in the foot. tSQLt Relies on having tests be only executed through the framework. If you call a test procedure directly you might see your data disappear. (It doesn’t actually, as long as you don’t panic.)

So, all that being said, your setup is probably safe, but I’m still going to advise against it.

Instead I recommend you install SQL Server developer edition on your own machine. It is free(!) and then if you accidentally mess up your local database you can just recreate it.

Answer 2

Why shouldn't I use tSQLt in production?

Sounds like a question for the tSQLt developers. But likely the concern is mostly related to performance implications both from locking and resource consumption. Resource consumption, when severe enough, can impact other databases on the same server.

Does tSQLt consume enough resources to affect your production database?...only the devs of it may be able to tell you, and even then they may not be able to conclusively say because it strongly depends on your server's existing workload and how it's provisioned from a hardware perspective.