जब मैं tSQLt faketable तालिका मैपिंग रीसेट नहीं करता है तो मैं कैसे पुनर्प्राप्त करूं?

Question

फ़ेकेबल फ़ंक्शन सामान्य पर पुन: असाइन नहीं किया गया था। मेरे सभी टेबल जो मैंने फ़ैकेट करने योग्य उपयोग किए हैं, अब यूनिट परीक्षण के सम्मिलन में उपयोग किए जाने वाले मानों की सामग्री शामिल हैं। यह कई टेबल था और उसने अपना डेटाबेस बेकार छोड़ दिया है। कृपया इस समस्या या कम से कम इसके कारण को हल करने में मदद करें। यह मुझे हमारे सीआई तैनाती प्रक्रिया में इसका उपयोग करने और हमारे स्थानीय विकास प्रयासों में शायद अधिक महत्वपूर्ण रूप से उपयोग करने के बारे में बहुत परेशान करता है।

Answer 1

यह आपके परीक्षणों या आपके कोड में से एक है, एक ऐसे राज्य में लेनदेन छोड़ दिया जहां इसे वापस नहीं किया जा सका। आमतौर पर परिणाम में "त्रुटि" ("सफलता" या "विफलता" के बजाय) के साथ एक या अधिक परीक्षण देखने में परिणाम होता है।

इन मामलों में, FakeTable ऑपरेशन वापस लुढ़का नहीं है, और टेबल को उनके पके हुए राज्य में छोड़ दिया गया है।

कवर के तहत, FakeTable तालिका का नाम बदलता है और इसकी एक नई प्रति बनाता है। जब नाम होता है, तो ऑपरेशन tSQLt.Private_RenamedObjectLog में लॉग होता है।

उदाहरण के लिए, आप एक त्रुटि है कि tSQLt शान से वापस नहीं किया जा सकता है पुन: पेश करने के लिए निम्न कोड का उपयोग कर सकते से:

SELECT OriginalName, SCHEMA_NAME(schema_id) + '.' + name AS [Name of Renamed Table], create_date 
FROM tSQLt.Private_RenamedObjectLog 
JOIN sys.objects ON ObjectId = object_id; 

:

EXEC tSQLt.NewTestClass 'SOF_Example' 
GO 

CREATE TABLE SOF_Example.MyTable (i INT); 
GO 

INSERT INTO SOF_Example.MyTable (i) VALUES (5); 
GO 

CREATE PROCEDURE SOF_Example.[test fake a table] 
AS 
BEGIN 
    EXEC tSQLt.FakeTable 'SOF_Example.MyTable'; 

    INSERT INTO SOF_Example.MyTable (i) VALUES (12); 

    COMMIT; 
END; 
GO 

EXEC tSQLt.Run 'SOF_Example'; 

आप का नाम बदला तालिका लॉग गौर करने के लिए इस कोड का उपयोग कर सकते

यदि आपने कई बार परीक्षण फिर से निष्पादित किए हैं, तो आपके पास प्रत्येक फ़ेक्ड टेबल के लिए लॉग में कई प्रविष्टियां हो सकती हैं। आप create_date का उपयोग यह निर्धारित करने में सहायता के लिए कर सकते हैं कि मूल डेटा में कौन सा है।

अब, सभी ने कहा: डेटाबेस में परीक्षण मामलों को लिखना और निष्पादित करना सबसे अच्छा है जहां आपको डेटा को संरक्षित करना होगा। सबसे अच्छा तरीका डेटाबेस का उपयोग करना है जिसमें कोई उपयोगकर्ता डेटा नहीं है (केवल सबसे आवश्यक कॉन्फ़िगरेशन डेटा)। आपको रिक्त डेटाबेस से विकास और इकाई परीक्षण होना चाहिए। आबादी वाले डेटाबेस ऐसे एकीकरण, प्रयोज्य, प्रदर्शन, आदि के रूप परीक्षण के अन्य रूपों, के लिए इस्तेमाल किया जाना चाहिए

Answer 2

मैं tSQLt के साथ एक ही समस्या थी, और tSQLt.Private_RenamedObjectLog

तालिका की सामग्री का उपयोग कर सब कुछ बहाल करने में सक्षम था

यह तालिका tSQLt ढांचे द्वारा बनाए रखी जाती है, और इसमें मूल सारणी के नाम शामिल होते हैं जो अस्थायी (यानी नकली) तालिकाओं के SQL ऑब्जेक्ट्स होते हैं। निम्नलिखित क्वेरी ने का उपयोग करते हुए नाटक किया तालिकाओं की सूची, और नाम है कि वे अस्थायी रूप से (यादृच्छिक ऐसे tSQLt_tempobject_3815e077fea84c7c रूप tSQLt द्वारा उत्पादित नाम) नाम दिया गया था:

SELECT   
    ObjectId, OriginalName, 
    OBJECT_SCHEMA_NAME(ObjectId) AS SchemaName, 
    OBJECT_NAME(ObjectId) AS TemporaryName 
FROM    
    tSQLt.Private_RenamedObjectLog 

SSMS में वस्तु एक्सप्लोरर रिफ्रेशिंग कि पता चला है इन यादृच्छिक नामों के साथ टेबल वास्तव में मौजूद थे, और वास्तव में उन्होंने मेरा मूल डेटा (whew !!) रखा था।

1. एक ROLLBACK TRANSACTION की कोशिश की सिर्फ मामले कि यह हल में:

   मैं उसके बाद निम्न किया था। ऐसा नहीं हुआ

2. डाटाबेस पर बैक किया गया (भले ही यह गड़बड़ हो गया हो)
3. फर्जी तालिकाओं को छोड़ दिया (यानी।मूल नाम, नहीं अस्थायी नाम)

4. साथ लोगों टेबल्स) नाम बदलकर (वापस उनके मूल नाम के लिए अस्थायी नाम के साथ, हर तालिका के लिए इस का उपयोग करते हुए:

   EXEC sp_rename 'schema.tempname', 'originalname'

5. साफ कर दिया गया के बाद मुझे पता था कि मेरी टेबल वापस थे तालिका tSQLt.Private_RenamedObjectLog,

   DELETE FROM tSQLt.Private_RenamedObjectLog

का उपयोग कर

स्वचालित रूप से पुनर्स्थापना स्क्रिप्ट का उत्पादन करने के लिए प्रक्रिया बनाना आसान होगा! हो सकता है कि पहले से ही tSQLt में कोई है - किसी को इसके बारे में पता है?

Answer 3

यह केवल टेबल को वापस स्थानांतरित करने में संभालता है (क्योंकि यह समस्या ओपी और मैं दोनों की समस्या थी) लेकिन तालिका को छोड़ने वाली रेखा के साथ बंदर शायद यह अन्य ऑब्जेक्ट प्रकारों के साथ काम करेगा।

DECLARE @cmd nvarchar(MAX) = ''; 

WITH x AS (
    SELECT TOP 10000 
      PL.Id           AS Id 
      ,PARSENAME(PL.OriginalName,1)      AS OriginalName 
      ,ISNULL(SO.name,'')        AS name 
      ,QUOTENAME(SCHEMA_NAME(ISNULL(SO.schema_id,1))) AS SchemaName 
      ,ISNULL(SEP.major_id,-1)       AS major_id 
     FROM tSQLt.Private_RenamedObjectLog PL 
     LEFT JOIN sys.objects SO 
     ON ObjectId = object_id 
     LEFT JOIN sys.extended_properties SEP 
     ON SEP.major_id = SO.object_id 
     AND SEP.name = 'tSQLt.FakeTable_OrgTableName' 
    ORDER BY SO.create_date DESC 
) 
SELECT @cmd = @cmd 
     + CASE WHEN x.name = '' OR OriginalName = x.name 
       THEN N'DELETE tSQLt.Private_RenamedObjectLog WHERE Id = ' + CAST(x.Id AS nvarchar) + N';' 
       ELSE N'DROP ' 
       + N'TABLE' --Replace this with a CASE statement to deal with other object types 
       + N' ' + SchemaName + '.' + QUOTENAME(x.OriginalName) + '; ' 
       + NCHAR(13) + NCHAR(10) + N'EXEC sp_rename ''' + SchemaName + N'.' 
             + QUOTENAME(x.name) + N''',''' + OriginalName + N''';' 
       + NCHAR(13) + NCHAR(10) + N'IF OBJECT_ID('''+SchemaName + N'.' + QUOTENAME(x.name)+N''') IS NULL' 
       + NCHAR(13) + NCHAR(10) + N'BEGIN' 
       + CASE WHEN x.major_id != -1 
         THEN NCHAR(13) + NCHAR(10) + N' EXEC sp_dropextendedproperty ''tSQLt.FakeTable_OrgTableName'',''SCHEMA'',''' 
          + PARSENAME(SchemaName,1) + N''',''TABLE'',''' + OriginalName + N''';' 
         ELSE '' 
        END 
       + NCHAR(13) + NCHAR(10) + N' DELETE tSQLt.Private_RenamedObjectLog WHERE Id = ' + CAST(x.Id AS nvarchar) + N';' 
       + NCHAR(13) + NCHAR(10) + N'END' 
     END 
     + NCHAR(13) + NCHAR(10) 
     + NCHAR(13) + NCHAR(10) 
    FROM x; 

--/* <-Remove leading dashes to execute 
PRINT @cmd; 
--*/EXEC (@cmd);