Easily preventable error: running faking sprocs outside of test's transaction

[tjlittle]

Hello,
We're experimenting with tSQLt. So far we love it, except for one small issue. It's definitely a n00b mistake, but since it's so easily preventable we thought we'd suggest a solution to prevent it.

In one of our first experiments with tSQLt, one of our developers wanted to run a snippet of the test he was developing, so he outlined it in SQL Server Management Studio and hit F5. Unfortunately, there was a call to tSQLt.FakeTable in the outlined snippet.

Since we were new to the framework, all we knew was that all the data in our table was gone - we didn't even know what had caused it to disappear. It was a test system, and we had backups anyway, so no harm done - however our confidence in tSQLt was severely shaken until we were able to guess what had happened, and find our data by looking in the renamed objects table.

It would be nice if the faking/spying functions all had some protection code in them to detect if they were being run inside a test run, and raise an error before any changes were made. Something similar to
IF @@TRANCOUNT = 0 RAISERROR('tSLQt.FakeTable called outside of a test session', 16, 10) perhaps?

It's not that big of a deal, but I think it could help new users of the framework immensely.

Thanks for your consideration,
Travis Little

[tjlittle]

Actually, here's the code snippet we used to give ourselves some training wheels.

   IF @@TRANCOUNT = 0 
   BEGIN
        RAISERROR('tSLQt.FakeTable called outside of a test session', 16, 10)
        RETURN
    END

[mbt1]

I will look into how to make this more safe for newbies. There are however people that use FakeTable outside of a transaction intentionally, and I don't want to break their tests.

[jeremysimmons]

+1 for making the change tjlittle suggested. Increment the version number to mark it as a breaking change.

+1 from me. We had a similar issue on a very large db and it took a whole day to resolve. It wasn't a noob mistake either, anyone can accidentally run an SP after a long tiring day, rather than running it using the tSQLt.Run proc

[nsturmwind]

I propose changing the function signature of FakeTable (and similar) to have an @EnableUseOutsideTransaction BIT = 0 parameter. This would be a breaking change for anyone who currently uses it outside transactions, but would require relatively minor changes to their tests.

If you feel that is too disruptive, then perhaps a database-level setting in tSQLt.Private_Configurations could be used, but my preference would be for the parameter.

Would this change be accepted by the maintainers?

[nsturmwind]

@mbt1 @dennislloydjr is the proposed change above acceptable?