डेटा संचालित डीयूनिट परीक्षण

Question

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

हालांकि डेटा का वास्तविक स्रोत महत्वपूर्ण नहीं है। कठिनाई DUnit डेटा-संचालित तरीके से व्यवहार कर रही है। इस समस्या के लिए, मान लीजिए कि डेटा स्रोत केवल एक यादृच्छिक संख्या जनरेटर था।

कुछ परीक्षण वस्तुओं (TTestCase या जो कुछ भी) रनटाइम पर बनाएँ, का कहना है कि उनमें से 10 है, जहां हर एक

1. रन टाइम पर नामित किया गया है: यहाँ एक उदाहरण ठोस समस्या यह है कि कठिनाई के दिल के हो जाता है एक यादृच्छिक रूप से जेनरेट पूर्णांक से। ('नाम' से मेरा मतलब है कि परीक्षण-धावक पेड़ में दिखाई देने वाले परीक्षण का नाम।)
2. यादृच्छिक पूर्णांक के आधार पर गुजरता है या विफल रहता है। यहां तक ​​कि, अजीब के लिए असफल।

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

या वैकल्पिक रूप से, क्या डुनीट के लिए कुछ विकल्प है जो मैं चाहता हूं?

Answer 1

program UnitTest1; 

{$IFDEF CONSOLE_TESTRUNNER} 
{$APPTYPE CONSOLE} 
{$ENDIF} 

uses 
    Forms, Classes, SysUtils, 
    TestFramework, 
    GUITestRunner, 
    TextTestRunner; 

{$R *.RES} 

type 
    TIntTestCase = class(TTestCase) 
    private 
    FValue: Integer; 
    public 
    constructor Create(AValue: Integer); reintroduce; 
    function GetName: string; override; 
    published 
    procedure Run; 
    end; 

{ TIntTestCase } 

constructor TIntTestCase.Create(AValue: Integer); 
begin 
    inherited Create('Run'); 
    FValue := AValue; 
end; 

function TIntTestCase.GetName: string; 
begin 
    Result := Format('Run_%.3d', [FValue]); 
end; 

procedure TIntTestCase.Run; 
begin 
    Check(FValue mod 2 = 0, Format('%d is not an even value', [FValue])); 
end; 

procedure RegisterTests; 
const 
    TestCount = 10; 
    ValueHigh = 1000; 
var 
    I: Integer; 
begin 
    Randomize; 
    for I := 0 to TestCount - 1 do 
    RegisterTest(TIntTestCase.Create(Random(ValueHigh) + 1)); 
end; 

begin 
    Application.Initialize; 
    RegisterTests; 
    if IsConsole then 
    TextTestRunner.RunRegisteredTests 
    else 
    GUITestRunner.RunRegisteredTests; 
end. 

Answer 2

मैं कहूंगा कि आप मूल रूप से एक "सुपर-टेस्ट" फ़ंक्शन चाहते हैं जो फिर अन्य परीक्षणों को कॉल करता है, प्रत्येक डेटा फ़ाइल के लिए एक। यह हम अपने डुनिट परीक्षणों में से एक के साथ करते हैं। आप बस एक लूप में प्रत्येक उपलब्ध फ़ाइल को लोड करते हैं, और जांच के साथ चेक को उचित के रूप में चलाते हैं।

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