Ich habe mein bestes getan, um der Weisheit in http://www.sommarskog.se/share_data.html und der tSQLt-Dokumentation zu folgen; versuchen, meine gespeicherten Prozeduren leicht und relativ unkomplex zu halten, so dass sie leicht testbar sind. So finde ich mich selbst eine temporäre Tabelle in einer primären gespeicherten Prozedur erstellen und dann auf dieser temporären Tabelle in "sekundären" gespeicherten Prozeduren arbeiten, die von der primären aufgerufen werden. Das funktioniert ziemlich gut, aber es erweist sich als etwas schwierig zu testen.Testen einer gespeicherten Prozedur, die auf der temporären Tabelle eines Aufrufers ausgeführt wird
Wenn Sie eine "sekundäre" gespeicherte Prozedur isoliert testen, muss die temporäre Tabelle bereits vorhanden sein. Es sieht so aus, als würde die Erstellung der temporären Tabelle in einer [Set Up]
-Prozedur nicht für die Komponententests beibehalten werden, sondern für eine vollständige Tabelle.
Also, um zu vermeiden, dass die CREATE TABLE #temp
in jeder Unit-Test zu wiederholen (mit seiner vollen Spaltendefinition), ich bin eine Variation der folgenden Aktionen ausführen:
EXEC tSQLt.NewTestClass 'SEtest';
GO
CREATE PROCEDURE [SEtest].[SetUp]
AS
BEGIN
CREATE TABLE SEtest.temptemplate (col1 int);
END;
GO
CREATE PROCEDURE [SEtest].[test example]
AS
BEGIN
-- Assemble
SELECT TOP (0) * INTO #temp FROM SEtest.temptemplate;
INSERT INTO #temp (col1)
VALUES (1),(2),(5),(7);
-- Act
EXEC dbo.REMOVE_EVEN_NUMBERS;
-- Assert
SELECT TOP (0) * INTO #expected FROM #temp;
INSERT INTO #expected (col1)
VALUES (1),(5),(7);
EXEC tSQLt.AssertEqualsTable '#expected', '#temp';
END;
GO
es irgendwelche bessere Möglichkeiten tSQLt mit Teilung in Einklang zu bringen Daten zwischen gespeicherten Prozeduren über temporäre Tabellen?
"Ich bin dabei, eine temporäre Tabelle in einer primären gespeicherten Prozedur zu erstellen und dann auf dieser temporären Tabelle in" sekundären "gespeicherten Prozeduren zu arbeiten, die von der primären aufgerufen werden" - Ich vermeide dieses Muster wo immer möglich. Sobald die Implementierung aus einer gespeicherten Prozedur "leckt", wird es schwieriger zu warten und zu testen. Eine Inline-Tabellenwert-Funktion kann oft eine Lösung sein –
Mitch, ich muss widersprechen. In diesem Kontext ist die Definition der Tabelle #temp Teil des Vertrags zwischen dem Sproc und dem Aufrufer.Daher ist es nicht schwierig, das Verfahren zu warten, wenn Sie die richtigen Tests durchführen. Allerdings stimme ich zu, dass es ein wenig hässlich ist (aber manchmal ist T-SQL hässlich). –
Das Einzige, was mir dabei helfen könnte, wäre eine prozessbasierte, permanente Tabelle. Solange es mir nichts ausmacht, dass die Performance nicht in tempdb liegt und ich ein zusätzliches Objekt in der Datenbank habe, kann ich es wahrscheinlich wie üblich in Tests testen. – NReilingh