C ++ के लिए अतुल्यकालिक इकाई परीक्षण

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

एक परिचय के रूप में, मैं यह नोट करना चाहता हूं कि मैं व्यक्तिगत रूप से अतुल्यकालिक परीक्षण पुस्तकालय के केवल एक कार्यान्वयन को देखने के लिए हुआ था, और वह केवल सिल्वरलाइट 3 और 4 के लिए (सिल्वरलाइट टूलकिट से)।

[TestClass] public class MyTest_test : SilverlightTest { [TestMethod] [Asynchronous]//    public void test_AsyncExample() { //      Thread cThread = new Thread( delegate() { //-   //   ! <b>EnqueueTestComplete();</b> } ); cThread.Start(); } } 

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

और इसलिए जिस टूल को हम आपके ध्यान में ला रहे हैं, उसे क्विकयूनिट कहा जाता है, यह एक खुली लाइब्रेरी है जो क्यूटी 4.7 का उपयोग करके क्यूटी 4.7 में लिखा गया है और एलजीपीएल 2.1 लाइसेंस के तहत वितरित किया गया है। क्यूटी पर इसे क्यों लागू किया गया है, लेकिन क्योंकि मेटाडेटा प्रणाली का इसका कार्यान्वयन अतुल्यकालिक परीक्षण समस्या को हल करने के लिए सबसे उपयुक्त है (यह मुझे .net में प्रतिबिंब की बहुत याद दिलाता है)। भविष्य में, .net और मोनो प्लेटफार्मों के लिए एक कार्यान्वयन की योजना बनाई गई है।

इससे पहले कि हम स्वयं पुस्तकालय पर विचार करना शुरू करें, आइए एक छोटे से उदाहरण पर गौर करें: कल्पना करें कि हमें उस कक्षा के लिए एक इकाई परीक्षण लिखना होगा जो पृष्ठभूमि थ्रेड में संचालन करता है। एक उदाहरण के लिए, हम QWebView :: load (...) विधि के लिए एक छोटा सा परीक्षण लिखेंगे, क्योंकि हम केवल सिग्नल प्रोसेसिंग लोडफिनिश (बूल) के माध्यम से इस फ़ंक्शन का परिणाम प्राप्त कर सकते हैं। तुलना के लिए, हम पहले CPPUNIT का उपयोग करके एक "सुपर सिंक्रोनस" टेस्ट लिखेंगे, और फिर QuickUnitit का उपयोग करके। और परिणाम की तुलना करें।

CPPUNIT का उपयोग करके लागू किए गए परीक्षण वर्ग पर विचार करें:

 #ifndef CWEBVIEWTEST_H #define CWEBVIEWTEST_H class CWebViewTest : public QObject, public CPPUNIT_NS::TestFixture { Q_OBJECT public: CWebViewTest( QObject *parent = 0 ); ~CWebViewTest(); CPPUNIT_TEST_SUITE( CWebViewTest ); CPPUNIT_TEST( test_WebView_Load ); CPPUNIT_TEST_SUITE_END(); public: //  virtual void setUp() { m_bPassed = false; m_pView = new QWebView( 0 ); }; //     virtual void tearDown() { delete m_pView; }; private: //  QWebView * m_pView; //    bool m_bPassed; private: //   void test_WebView_Load() { connect( m_pView, SIGNAL( loadFinished( bool ) ), SLOT( slot_load_finished( bool ) ) ); m_pView->load( QUrl("http://www.google.ru") ); /*      ,         loadFinished( bool ) */ //    (    ) while ( !m_bPassed ) { QApplication::processEvents( QEventLoop::ExcludeUserInputEvents ); } } private slots: void slot_load_finished( bool bOk ) { CPPUNIT_ASSERT(bOk); CPPUNIT_ASSERT( m_pView->page()->totalBytes() > 100 ); m_bPassed = true;//   } }; #endif // CWEBVIEWTEST_H 

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

 //    (    ) while ( !m_bPassed ) { QApplication::processEvents( QEventLoop::ExcludeUserInputEvents ); } 

हालाँकि, यह विधि प्रोसेसर के लिए समय लेने वाली है, बेशक यह घातक नहीं है, लेकिन यह परीक्षण और विकास के चरण में यह स्पष्ट नहीं करता है कि आप जिस कोड को लागू करते हैं वह वास्तव में प्रोसेसर को कैसे लोड करता है।

अब उसी समस्या पर विचार करें, लेकिन QuickUnit का उपयोग करते हुए:

 #ifndef ASYNCHRONOUS_TEST_EXAMPLE_H #define ASYNCHRONOUS_TEST_EXAMPLE_H #include <QS_QuickUnit.h> #include <QtWebKit\QtWebKit> class AsynchronousTestExample : public QS_TestClass { Q_OBJECT private: QWebView * m_pView; private slots: //  void test_LoadWebPage() { QS_BEGIN_TEST; m_pView = new QWebView( 0 ); connect( m_pView, SIGNAL( loadFinished( bool ) ), SLOT( slot_loadFinished( bool ) ) ); m_pView->load( QUrl( "http://custom.site.com" ) ); QS_END_TEST; }//      ,     ! //  (    , //      test_) void slot_loadFinished ( bool ok ) { QS_BEGIN_TEST; //  QS_IS_TRUE( ok ); QS_IS_TRUE( m_pView->page()->totalBytes() > 100 ); QS_END_TEST; QS_TEST_COMPLETE;//,     } }; #endif //ASYNCHRONOUS_TEST_EXAMPLE_H 

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

1. यदि डेवलपर यह इंगित करना भूल जाता है कि परीक्षण पूरा होना चाहिए, तो सिस्टम हमेशा के लिए प्रतीक्षा करेगा (हमारे पास ऐसे मामलों के लिए एक समय सीमा शामिल करने की योजना है, ताकि पूरा होने के लिए परीक्षण प्रक्रिया पूरी तरह से धीमा न हो);
2. यह पुस्तकालय क्यूटी पर लागू किया गया है, अर्थात QuickUnit का उपयोग करने से पहले, आपको पहले क्यूटी को स्थापित करना होगा, और यदि आप Visual Studio का उपयोग करते हैं तो स्टूडियो के लिए ऐड-ऑन।
   

संक्षेप में:

अगर हम क्विक यूनिट का उपयोग करते हैं तो हमें क्या मिलेगा:

1. परीक्षण फ़ंक्शन में प्रवाह को बनाए रखने के लिए पहेली की आवश्यकता नहीं है;
2. परीक्षण वर्ग का न्यूनतम घोषित हिस्सा;
3. बिल्डिंग परीक्षणों में लचीलापन, जटिल परीक्षण के लिए, कोड के बहुत सारे थ्रेड ब्लॉक हैं;
4. छोटे पुस्तकालय का आकार
5. क्रॉस प्लेटफॉर्म।

नुकसान:

1. क्यूटी के लिए स्नैप;
2. सावधानीपूर्वक परीक्षण लिखें, पूरा करने के बारे में मत भूलना।

QuickUnit की बुनियादी आवश्यकताओं और विशेषताओं पर एक संक्षिप्त नज़र।

टेस्ट क्लास में ही QS_TestClass का वंशज होना चाहिए और क्यूटी क्लास (Q_OBJECT मैक्रो घोषित है)। बाहरी लोगों से परीक्षण स्लॉट अलग करने के लिए, पूर्व में उपसर्ग test_ है। सभी परीक्षण स्लॉट मुख्य धागे के संदर्भ में निष्पादित किए जाते हैं, जो आपको एक शब्द में GUI कक्षाएं, COM ऑब्जेक्ट का उपयोग करने की अनुमति देता है, उन सभी वर्गों को जो केवल एप्लिकेशन के मुख्य धागे के संदर्भ में बनाया जा सकता है।

टेस्ट स्लॉट को महत्वपूर्ण और गैर-महत्वपूर्ण दो श्रेणियों में विभाजित किया गया है। क्रिटिकल टेस्ट स्लॉट - पूरे टेस्ट क्लास के लिए महत्वपूर्ण है, अगर यह टेस्ट में उत्तीर्ण नहीं हुआ, तो आगे के टेस्ट स्लॉट को निष्पादित नहीं किया जाएगा, नियंत्रण को अगले टेस्ट क्लास में स्थानांतरित कर दिया जाएगा। परीक्षण पूरा कर लिया है कि प्रणाली को इंगित करने के लिए, मैक्रो QS_TEST_COMPLETE, का उपयोग किया जाता है। इस दृष्टिकोण के लिए धन्यवाद, किसी भी अतुल्यकालिक एल्गोरिथ्म के परीक्षण को आसानी से लागू किया जा सकता है।

टेस्ट स्लॉट में विशेषताओं का एक सेट होता है। विशेषता का कार्य सिस्टम को यह बताना है कि स्लॉट को कुछ सुविधाओं के साथ चलाया जाना चाहिए। घोषणा को कम करने के लिए, परीक्षण स्लॉट के नाम में विशेषताएँ शामिल हैं, उदाहरण के लिए:

 #ifndef ATTRIBUTE_USAGE_EXAMPLE_H #define ATTRIBUTE_USAGE_EXAMPLE_H #include <QS_QuickUnit.h> class AttributeUsageExample : public QS_TestClass { Q_OBJECT private slots: void test_myTest_Fatal() { QS_BEGIN_TEST; //   QS_END_TEST; QS_TEST_COMPLETE; } void test_myTest_Repeat_15() { QS_BEGIN_TEST; //   QS_END_TEST; QS_TEST_COMPLETE; } void test_myTest_Fatal_Repeat_15() { QS_BEGIN_TEST; //   QS_END_TEST; QS_TEST_COMPLETE; } }; #endif //ATTRIBUTE_USAGE_EXAMPLE_H 

वर्तमान संस्करण में, अब तक केवल दो विशेषताएँ _Fatal और _Repeat_N लागू की गई हैं। पहला इंगित करता है कि स्लॉट महत्वपूर्ण है, और दूसरा इंगित करता है कि स्लॉट को एक पंक्ति में एन बार फिर से कहा जाना चाहिए। डिफ़ॉल्ट रूप से, परीक्षण स्लॉट महत्वपूर्ण नहीं है और केवल एक बार चलता है। मैक्रोज़ QS_BEGIN_TEST और QS_END_TEST एक प्रयास कैच ब्लॉक है। अपवाद को पकड़ने के मामले में, परीक्षण स्लॉट बाधित हो जाएगा और इसे वैध नहीं के रूप में तय किया जाएगा। परीक्षण मैक्रोज़ का एक समूह भी है, आप उन्हें डेवलपर के गाइड में पा सकते हैं। परीक्षण वर्ग का वर्णन करने के बाद, यह केवल इसे पंजीकृत करने के लिए रहता है। पंजीकरण को main.cpp में लागू करने की सिफारिश की गई है

क्विक यूनिट न केवल क्यूटी के तहत परीक्षण के लिए उपयुक्त है, बल्कि पूरी तरह से Win32, ATL, MFC के साथ भी संगत है। परीक्षण के परिणामों के आधार पर, कंसोल उत्तीर्ण किए गए परीक्षणों पर एक रिपोर्ट प्रदर्शित करता है, त्रुटियों के कारणों और बिंदुओं को दर्शाता है, रिपोर्ट में परीक्षण स्लॉट, कक्षा का निष्पादन समय भी शामिल है।

हमें पूरी उम्मीद है कि QuickUnit आपकी समस्याओं को हल करने में मदद करेगा। सभी सुझावों और टिप्पणियों को यहां छोड़ा जा सकता है ।