Question about tSQLt.Fail design

[ay-azara]

Hey, this isn't really an issue and I think I already know the answer but figured I'd ask anyway.

The code below fails if you call something like tsqlt.AssertEquals(0, 1, 'Fail message') outside the test runner. I ran into this while debugging some tests interactively; create some temp code, select code, execute code type stuff.

tSQLt/Source/tSQLt.Fail.ssp.sql

Lines 40 to 51 in 60a1cc8

	INSERT INTO #TestMessage(Msg)
	SELECT COALESCE(@Message0, '!NULL!')
	+ COALESCE(@Message1, '!NULL!')
	+ COALESCE(@Message2, '!NULL!')
	+ COALESCE(@Message3, '!NULL!')
	+ COALESCE(@Message4, '!NULL!')
	+ COALESCE(@Message5, '!NULL!')
	+ COALESCE(@Message6, '!NULL!')
	+ COALESCE(@Message7, '!NULL!')
	+ COALESCE(@Message8, '!NULL!')
	+ COALESCE(@Message9, '!NULL!')
	+ @WarningMessage;

The table is created by tSQLt.Private_RunTest_TestExecution so I assume the expectation is that you'd never run tsqlt procs without the test runner but would there be a problem if tsqlt.Fail checked for the table and created it if it didn't exist as a fallback? It'd be cool if RAISERROR included the failure message but again my usage is outside the norm so I'm probably barking up the wrong tree :)

   IF OBJECT_ID(N'tempdb..#TestMessage') IS NULL
	CREATE TABLE #TestMessage(Msg NVARCHAR(MAX));