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

सामान्य तौर पर, अभिनेताओं का उपयोग करके बहु-थ्रेडेड एप्लिकेशन लिखना आसान और सुखद है। जिसमें शामिल हैं क्योंकि अभिनेता स्वयं आसानी से और स्वाभाविक रूप से लिखे गए हैं। आप यहां तक ​​कह सकते हैं कि अभिनेता कोड लिखना नौकरी का सबसे आसान हिस्सा है। लेकिन जब अभिनेता लिखा जाता है, तो एक बहुत अच्छा सवाल उठता है: "अपने काम की शुद्धता की जांच कैसे करें?"

सवाल वाकई बहुत अच्छा है। जब हम सामान्य रूप से अभिनेताओं के बारे में बात करते हैं और विशेष रूप से SObjectizer के बारे में हमसे नियमित रूप से पूछा जाता है। और कुछ समय पहले तक, हम केवल सामान्य शब्दों में इस प्रश्न का उत्तर दे सकते थे।

लेकिन संस्करण 5.5.24 जारी किया गया था , जिसमें अभिनेताओं के यूनिट-परीक्षण की संभावना के लिए प्रयोगात्मक समर्थन था। और इस लेख में हम इस बारे में बात करने की कोशिश करेंगे कि यह क्या है, इसका उपयोग कैसे किया जाए और इसे लागू कैसे किया गया।

अभिनेता परीक्षण क्या दिखते हैं?

हम कुछ उदाहरणों पर SObjectizer की नई विशेषताओं पर विचार करेंगे, जो साथ में चल रही हैं। चर्चा किए गए उदाहरणों के लिए स्रोत कोड इस भंडार में पाया जा सकता है ।

पूरी कहानी के दौरान, "अभिनेता" और "एजेंट" शब्दों का परस्पर उपयोग किया जाएगा। वे एक ही चीज़ को नामित करते हैं, लेकिन SObjectizer में "एजेंट" शब्द ऐतिहासिक रूप से उपयोग किया जाता है, इसलिए आगे "एजेंट" का उपयोग अधिक बार किया जाएगा।

Pinger और Ponger के साथ सबसे सरल उदाहरण

अभिनेता Pinger और Ponger का उदाहरण संभवतः अभिनेता के ढांचे के लिए सबसे आम उदाहरण है। इसे एक क्लासिक कहा जा सकता है। ठीक है, यदि ऐसा है, तो क्लासिक्स से शुरू करें।

तो, हमारे पास एक Pinger Agent है, जो अपने काम की शुरुआत में Ponger एजेंट को एक पिंग संदेश भेजता है। और Ponger एजेंट एक Pong संदेश वापस भेजता है। यह C ++ कोड में कैसा दिखता है:

// Types of signals to be used. struct ping final : so_5::signal_t {}; struct pong final : so_5::signal_t {}; // Pinger agent. class pinger_t final : public so_5::agent_t { so_5::mbox_t m_target; public : pinger_t( context_t ctx ) : so_5::agent_t{ std::move(ctx) } { so_subscribe_self().event( [this](mhood_t<pong>) { so_deregister_agent_coop_normally(); } ); } void set_target( const so_5::mbox_t & to ) { m_target = to; } void so_evt_start() override { so_5::send< ping >( m_target ); } }; // Ponger agent. class ponger_t final : public so_5::agent_t { so_5::mbox_t m_target; public : ponger_t( context_t ctx ) : so_5::agent_t{ std::move(ctx) } { so_subscribe_self().event( [this](mhood_t<ping>) { so_5::send< pong >( m_target ); } ); } void set_target( const so_5::mbox_t & to ) { m_target = to; } }; 

हमारा कार्य एक परीक्षण लिखना है जो यह सत्यापित करेगा कि इन एजेंटों को एसबिजाइज़र के साथ पंजीकृत करने पर, पोंगर को एक पिंग संदेश प्राप्त होगा, और पिंगर को प्रतिक्रिया में एक पोंग संदेश प्राप्त होगा।

ठीक है। हम इस तरह के परीक्षण को doctest यूनिट-टेस्ट फ्रेमवर्क का उपयोग करके लिखते हैं और प्राप्त करते हैं:

 #define DOCTEST_CONFIG_IMPLEMENT_WITH_MAIN #include <doctest/doctest.h> #include <ping_pong/agents.hpp> #include <so_5/experimental/testing.hpp> namespace tests = so_5::experimental::testing; TEST_CASE( "ping_pong" ) { tests::testing_env_t sobj; pinger_t * pinger{}; ponger_t * ponger{}; sobj.environment().introduce_coop([&](so_5::coop_t & coop) { pinger = coop.make_agent< pinger_t >(); ponger = coop.make_agent< ponger_t >(); pinger->set_target( ponger->so_direct_mbox() ); ponger->set_target( pinger->so_direct_mbox() ); }); sobj.scenario().define_step("ping") .when(*ponger & tests::reacts_to<ping>()); sobj.scenario().define_step("pong") .when(*pinger & tests::reacts_to<pong>()); sobj.scenario().run_for(std::chrono::milliseconds(100)); REQUIRE(tests::completed() == sobj.scenario().result()); } 

यह आसान लग रहा है। देखते हैं कि यहां क्या होता है।

सबसे पहले, हम एजेंट परीक्षण समर्थन उपकरणों के विवरण डाउनलोड करते हैं:

 #include <so_5/experimental/testing.hpp> 

ये सभी उपकरण so_5 :: प्रयोगात्मक :: परीक्षण नामस्थान में वर्णित हैं, लेकिन इतने लंबे नाम को दोहराने के लिए नहीं, हम एक छोटे और अधिक सुविधाजनक उपनाम का परिचय देते हैं:

 namespace tests = so_5::experimental::testing; 

निम्नलिखित एक एकल परीक्षण मामले का वर्णन है (और हमें यहां और अधिक की आवश्यकता नहीं है)।

परीक्षण मामले के अंदर, कई महत्वपूर्ण बिंदु हैं।

सबसे पहले, यह SObjectizer के लिए एक विशेष परीक्षण वातावरण का निर्माण और प्रक्षेपण है:

 tests::testing_env_t sobj; 

इस माहौल के बिना, एजेंटों के लिए "टेस्ट रन" पूरा नहीं किया जा सकता है, लेकिन हम इस बारे में थोड़ी देर बाद बात करेंगे।

Test_env_t वर्ग SObjectizer में लिपटे_env_t वर्ग के समान है। उसी तरह, एसओबीजेलाइज़र कंस्ट्रक्टर में शुरू होता है, और विध्वंसक में रुक जाता है। इसलिए परीक्षण लिखते समय, आपको SObjectizer शुरू करने और रोकने के बारे में नहीं सोचना चाहिए।

अगला, हमें Pinger और Ponger एजेंट बनाने और पंजीकृत करने की आवश्यकता है। इस मामले में, हमें तथाकथित को निर्धारित करने में इन एजेंटों का उपयोग करने की आवश्यकता है। "परीक्षण परिदृश्य।" इसलिए, हम अलग से पॉइंटर्स को एजेंट्स में स्टोर करते हैं:

 pinger_t * pinger{}; ponger_t * ponger{}; sobj.environment().introduce_coop([&](so_5::coop_t & coop) { pinger = coop.make_agent< pinger_t >(); ponger = coop.make_agent< ponger_t >(); pinger->set_target( ponger->so_direct_mbox() ); ponger->set_target( pinger->so_direct_mbox() ); }); 

और फिर हम "परीक्षण परिदृश्य" के साथ काम करना शुरू करते हैं।

एक टेस्ट केस एक ऐसा टुकड़ा होता है जिसमें चरणों का एक सीधा क्रम होता है जिसे शुरू से अंत तक पूरा किया जाना चाहिए। वाक्यांश "एक प्रत्यक्ष अनुक्रम से" का अर्थ है कि SObjectizer-5.5.24 में स्क्रिप्ट चरण "कार्य" सख्ती से क्रमिक रूप से, बिना किसी शाखा या लूप के।

एजेंटों के लिए एक परीक्षण लिखना एक परीक्षण स्क्रिप्ट की परिभाषा है जिसे निष्पादित करने की आवश्यकता है। यानी परीक्षण परिदृश्य के सभी चरणों को पहले से बहुत आखिरी तक काम करना चाहिए।

इसलिए, हमारे परीक्षण के मामले में, हम दो-चरण परिदृश्य को परिभाषित करते हैं। पहला चरण सत्यापित करता है कि पोंगर एजेंट पिंग संदेश प्राप्त करेगा और उसे संसाधित करेगा:

 sobj.scenario().define_step("ping") .when(*ponger & tests::reacts_to<ping>()); 

दूसरा चरण यह जाँचता है कि Pinger एजेंट को Pong संदेश प्राप्त होता है:

 sobj.scenario().define_step("pong") .when(*pinger & tests::reacts_to<pong>()); 

ये दो चरण हमारे परीक्षण के मामले के लिए काफी पर्याप्त हैं, इसलिए, उनके निर्धारण के बाद, हम स्क्रिप्ट के निष्पादन के लिए आगे बढ़ते हैं। हम स्क्रिप्ट चलाते हैं और इसे 100ms से अधिक नहीं चलने देते हैं:

 sobj.scenario().run_for(std::chrono::milliseconds(100)); 

संदेशों के आदान-प्रदान के लिए सौ एजेंटों को दो एजेंटों के लिए पर्याप्त से अधिक होना चाहिए (भले ही परीक्षण बहुत धीमी गति से आभासी मशीन के अंदर चलाया जाता है, जैसा कि कभी-कभी ट्रैविस सीआई के साथ होता है)। ठीक है, अगर हमने एजेंटों को लिखने में गलती की है या गलत तरीके से परीक्षण स्क्रिप्ट का वर्णन किया है, तो 100 से अधिक के लिए एक गलत स्क्रिप्ट के पूरा होने का इंतजार करने का कोई मतलब नहीं है।

इसलिए, run_for () से लौटने के बाद, हमारी स्क्रिप्ट या तो सफलतापूर्वक पूरी हो सकती है या नहीं। इसलिए, हम बस स्क्रिप्ट के परिणाम की जांच करते हैं:

 REQUIRE(tests::completed() == sobj.scenario().result()); 

यदि स्क्रिप्ट सफलतापूर्वक पूरी नहीं हुई, तो इससे हमारे परीक्षण के मामले में विफलता होगी।

कुछ स्पष्टीकरण और परिवर्धन

यदि हम एक सामान्य SObjectizer के अंदर इस कोड को चलाते हैं:

 pinger_t * pinger{}; ponger_t * ponger{}; sobj.environment().introduce_coop([&](so_5::coop_t & coop) { pinger = coop.make_agent< pinger_t >(); ponger = coop.make_agent< ponger_t >(); pinger->set_target( ponger->so_direct_mbox() ); ponger->set_target( pinger->so_direct_mbox() ); }); 

फिर, सबसे अधिक संभावना है, Pinger और Ponger एजेंट संदेश का आदान-प्रदान करने और अपने काम को पूरा करने से पहले ही परिचय_कोप (मल्टीथ्रेडिंग के चमत्कार ऐसे हैं) का प्रबंधन करेंगे। लेकिन परीक्षण के वातावरण के अंदर, जो test_env_t के लिए धन्यवाद बनाया गया है, ऐसा नहीं होता है, पिंगर और पोंगर एजेंट धैर्यपूर्वक प्रतीक्षा करते हैं जब तक हम अपनी परीक्षण स्क्रिप्ट नहीं चलाते हैं। यह कैसे होता है?

तथ्य यह है कि परीक्षण वातावरण के अंदर, एजेंट जमे हुए राज्य में दिखाई देते हैं। यानी पंजीकरण के बाद, वे SObjectizer में मौजूद हैं, लेकिन वे अपने किसी भी संदेश को संसाधित नहीं कर सकते। इसलिए, यहां तक ​​कि so_evt_start () को परीक्षण स्क्रिप्ट चलाने से पहले एजेंटों के लिए नहीं बुलाया जाता है।

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

जब इस तरह की सूचनाएं परीक्षण स्क्रिप्ट पर आने लगती हैं, तो स्क्रिप्ट उन्हें पहले चरण में "कोशिश" करने की कोशिश करती है। तो, हमारे पास एक सूचना है कि पोंगर ने पिंग को प्राप्त किया और संसाधित किया - यह हमारे लिए दिलचस्प है या नहीं? यह पता चला है कि यह दिलचस्प है, क्योंकि कदम का वर्णन बिल्कुल यही कहता है: यह तब काम करता है जब पोंगर पिंग पर प्रतिक्रिया करता है। हम कोड में क्या देखते हैं:

 .when(*ponger & tests::reacts_to<ping>()) 

ठीक है। तो पहला कदम काम किया, अगले चरण पर जाएं।

इसके बाद एक अधिसूचना आती है कि एजेंट पिंगर ने पोंग को प्रतिक्रिया दी है। और यह वही है जो आपको काम करने के लिए दूसरे चरण के लिए चाहिए:

 .when(*pinger & tests::reacts_to<pong>()) 

ठीक है। तो दूसरा कदम काम किया, क्या हमारे पास कुछ और है? नहीं। इसका मतलब है कि संपूर्ण परीक्षण स्क्रिप्ट पूरी हो गई है और आप run_for () से नियंत्रण वापस कर सकते हैं।

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

उदाहरण दार्शनिक दर्शन

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

फोर्क और दार्शनिक एजेंटों के कार्यान्वयन के साथ स्रोत कोड यहां मिल सकते हैं , लेख में हम उन्हें अंतरिक्ष को बचाने के लिए विचार नहीं करेंगे।

कांटा के लिए परीक्षण

डाइनिंग फिलोसॉफर्स के एजेंटों के लिए पहला परीक्षण एजेंट फोर्क के लिए होगा।

यह एजेंट एक साधारण योजना के अनुसार काम करता है। उसके दो राज्य हैं: फ्री और टेकन। जब एजेंट फ्री स्टेट में होता है, तो वह टेक संदेश का जवाब देता है। इस मामले में, एजेंट टेकन राज्य में प्रवेश करता है और टेकन प्रतिक्रिया संदेश के साथ प्रतिक्रिया करता है।

जब एजेंट टेकन राज्य में होता है, तो वह संदेश को अलग तरीके से लेता है: एजेंट की स्थिति नहीं बदलती है, और व्यस्तता को प्रतिक्रिया संदेश के रूप में भेजा जाता है। टेकन राज्य में भी, एजेंट पुट संदेश का जवाब देता है: एजेंट मुक्त राज्य में लौटता है।

मुक्त अवस्था में, पुट संदेश को अनदेखा किया जाता है।

हम निम्नलिखित परीक्षण मामले के माध्यम से इस एक का परीक्षण करने की कोशिश करेंगे:

 TEST_CASE( "fork" ) { class pseudo_philosopher_t final : public so_5::agent_t { public: pseudo_philosopher_t(context_t ctx) : so_5::agent_t{std::move(ctx)} { so_subscribe_self() .event([](mhood_t<msg_taken>) {}) .event([](mhood_t<msg_busy>) {}); } }; tests::testing_env_t sobj; so_5::agent_t * fork{}; so_5::agent_t * philosopher{}; sobj.environment().introduce_coop([&](so_5::coop_t & coop) { fork = coop.make_agent<fork_t>(); philosopher = coop.make_agent<pseudo_philosopher_t>(); }); sobj.scenario().define_step("put_when_free") .impact<msg_put>(*fork) .when(*fork & tests::ignores<msg_put>()); sobj.scenario().define_step("take_when_free") .impact<msg_take>(*fork, philosopher->so_direct_mbox()) .when_all( *fork & tests::reacts_to<msg_take>() & tests::store_state_name("fork"), *philosopher & tests::reacts_to<msg_taken>()); sobj.scenario().define_step("take_when_taken") .impact<msg_take>(*fork, philosopher->so_direct_mbox()) .when_all( *fork & tests::reacts_to<msg_take>(), *philosopher & tests::reacts_to<msg_busy>()); sobj.scenario().define_step("put_when_taken") .impact<msg_put>(*fork) .when( *fork & tests::reacts_to<msg_put>() & tests::store_state_name("fork")); sobj.scenario().run_for(std::chrono::milliseconds(100)); REQUIRE(tests::completed() == sobj.scenario().result()); REQUIRE("taken" == sobj.scenario().stored_state_name("take_when_free", "fork")); REQUIRE("free" == sobj.scenario().stored_state_name("put_when_taken", "fork")); } 

बहुत सारे कोड हैं, इसलिए हम उन हिस्सों से निपटेंगे, जो उन टुकड़ों को छोड़ देंगे जो पहले से ही स्पष्ट होना चाहिए।

पहली चीज़ जो हमें यहाँ चाहिए वह है असली फिलोसोफ़र एजेंट को बदलना। एक फोर्क एजेंट को किसी से संदेश प्राप्त करना चाहिए और किसी को जवाब देना चाहिए। लेकिन हम इस परीक्षण मामले में वास्तविक दार्शनिक का उपयोग नहीं कर सकते हैं, क्योंकि वास्तविक दार्शनिक एजेंट का अपना व्यवहार तर्क है, वह स्वयं संदेश भेजता है और यह स्वतंत्रता हमारे यहां हस्तक्षेप करेगी।

इसलिए, हम मॉकिंग करते हैं, अर्थात्। वास्तविक दार्शनिक के बजाय, हम इसके लिए एक विकल्प प्रस्तुत करेंगे: एक खाली एजेंट जो स्वयं कुछ भी नहीं भेजता है, लेकिन केवल किसी भी उपयोगी प्रसंस्करण के बिना भेजे गए संदेशों को प्राप्त करता है। यह कोड में लागू छद्म-फिलोसोफर है:

 class pseudo_philosopher_t final : public so_5::agent_t { public: pseudo_philosopher_t(context_t ctx) : so_5::agent_t{std::move(ctx)} { so_subscribe_self() .event([](mhood_t<msg_taken>) {}) .event([](mhood_t<msg_busy>) {}); } }; 

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

स्क्रिप्ट का पहला चरण यह सत्यापित करना है कि फ़र्क, फ़्री स्टेट में होना (और यह इसकी प्रारंभिक स्थिति है), पुट संदेश का जवाब नहीं देता है। यहां बताया गया है कि यह जांच कैसे लिखी गई है:

 sobj.scenario().define_step("put_when_free") .impact<msg_put>(*fork) .when(*fork & tests::ignores<msg_put>()); 

ध्यान आकर्षित करने वाली पहली चीज प्रभाव निर्माण है।

उसे जरूरत है क्योंकि हमारे एजेंट फोर्क खुद कुछ नहीं करते हैं, वह केवल आने वाले संदेशों पर प्रतिक्रिया करता है। इसलिए, किसी को एजेंट को संदेश भेजना चाहिए। लेकिन कौन?

लेकिन स्क्रिप्ट स्टेप स्वयं प्रभाव से भेजता है। वास्तव में, प्रभाव सामान्य भेजने के कार्य का एक एनालॉग है (और प्रारूप समान है)।

खैर, स्क्रिप्ट स्टेप ही प्रभाव के माध्यम से एक संदेश भेजेगा। लेकिन वह कब करेगा?

और जब बारी आएगी तब वह ऐसा करेंगे। यानी यदि स्क्रिप्ट में कदम पहले है, तो प्रभाव को run_for दर्ज करने के तुरंत बाद निष्पादित किया जाएगा। यदि स्क्रिप्ट में कदम पहले नहीं है, तो प्रभाव को निष्पादित किया जाएगा जैसे ही पिछले चरण ने काम किया है और स्क्रिप्ट अगले चरण को संसाधित करने के लिए आगे बढ़ेगी।

दूसरी बात जिस पर हमें यहाँ चर्चा करने की आवश्यकता है, वह है इग्नोर। यह सहायक फ़ंक्शन कहता है कि जब एजेंट संदेश को संसाधित करने में विफल रहता है तो चरण चालू हो जाता है। यानी इस स्थिति में, Fork एजेंट को पुट संदेश को संसाधित करने से इनकार करना चाहिए।

आइए परीक्षण परिदृश्य के एक और चरण पर अधिक विस्तार से विचार करें:

 sobj.scenario().define_step("take_when_free") .impact<msg_take>(*fork, philosopher->so_direct_mbox()) .when_all( *fork & tests::reacts_to<msg_take>() & tests::store_state_name("fork"), *philosopher & tests::reacts_to<msg_taken>()); 

सबसे पहले, यहाँ हम देखते हैं कि कब, कब के बजाय। ऐसा इसलिए है क्योंकि एक कदम को ट्रिगर करने के लिए, हमें एक साथ कई शर्तों को पूरा करना होगा। टेक को संभालने के लिए कांटा एजेंट की जरूरत है। और दार्शनिक को टेकन की प्रतिक्रिया को संभालने की जरूरत है। इसलिए, हम लिखते हैं कि कब, कब नहीं। वैसे, जब_ कोई भी हो, लेकिन हम आज के उदाहरणों में उनसे नहीं मिलेंगे।

दूसरे, हमें इस तथ्य की भी जांच करने की आवश्यकता है कि टेक प्रसंस्करण के बाद, फोर्क एजेंट टेकन राज्य में होगा। हम निम्नानुसार जांच करते हैं: पहले हम इंगित करते हैं कि जैसे ही फोर्क एजेंट प्रसंस्करण समाप्त कर लेता है, उसकी वर्तमान स्थिति का नाम "कांटा" टैग का उपयोग करके बचाया जाना चाहिए। यह निर्माण एजेंट के राज्य का नाम रखता है:

 & tests::store_state_name("fork") 

और फिर, जब स्क्रिप्ट सफलतापूर्वक पूरी हो जाती है, तो हम इस सहेजे गए नाम की जाँच करते हैं:

 REQUIRE("taken" == sobj.scenario().stored_state_name("take_when_free", "fork")); 

यानी हम स्क्रिप्ट से पूछते हैं: हमें उस नाम को दें जो for_ टैग के साथ save_when_free नाम के चरण के लिए सहेजा गया था, और फिर अपेक्षित मान के साथ नाम की तुलना करें।

यहाँ, शायद, वह सब है जो कांटा एजेंट के लिए परीक्षण के मामले में नोट किया जा सकता है। अगर पाठकों के पास कोई सवाल है, तो टिप्पणियों में पूछें, हम खुशी के साथ जवाब देंगे।

दार्शनिक के लिए सफल स्क्रिप्ट टेस्ट

दार्शनिक एजेंट के लिए, हम केवल एक परीक्षण मामले पर विचार करेंगे - उस मामले के लिए जब दार्शनिक दोनों कांटे ले सकते हैं और खा सकते हैं।

यह परीक्षण मामला इस तरह दिखेगा:

 TEST_CASE( "philosopher (takes both forks)" ) { tests::testing_env_t sobj{ [](so_5::environment_params_t & params) { params.message_delivery_tracer( so_5::msg_tracing::std_cout_tracer()); } }; so_5::agent_t * philosopher{}; so_5::agent_t * left_fork{}; so_5::agent_t * right_fork{}; sobj.environment().introduce_coop([&](so_5::coop_t & coop) { left_fork = coop.make_agent<fork_t>(); right_fork = coop.make_agent<fork_t>(); philosopher = coop.make_agent<philosopher_t>( "philosopher", left_fork->so_direct_mbox(), right_fork->so_direct_mbox()); }); auto scenario = sobj.scenario(); scenario.define_step("stop_thinking") .when( *philosopher & tests::reacts_to<philosopher_t::msg_stop_thinking>() & tests::store_state_name("philosopher") ) .constraints( tests::not_before(std::chrono::milliseconds(250)) ); scenario.define_step("take_left") .when( *left_fork & tests::reacts_to<msg_take>() ); scenario.define_step("left_taken") .when( *philosopher & tests::reacts_to<msg_taken>() & tests::store_state_name("philosopher") ); scenario.define_step("take_right") .when( *right_fork & tests::reacts_to<msg_take>() ); scenario.define_step("right_taken") .when( *philosopher & tests::reacts_to<msg_taken>() & tests::store_state_name("philosopher") ); scenario.define_step("stop_eating") .when( *philosopher & tests::reacts_to<philosopher_t::msg_stop_eating>() & tests::store_state_name("philosopher") ) .constraints( tests::not_before(std::chrono::milliseconds(250)) ); scenario.define_step("return_forks") .when_all( *left_fork & tests::reacts_to<msg_put>(), *right_fork & tests::reacts_to<msg_put>() ); scenario.run_for(std::chrono::seconds(1)); REQUIRE(tests::completed() == scenario.result()); REQUIRE("wait_left" == scenario.stored_state_name("stop_thinking", "philosopher")); REQUIRE("wait_right" == scenario.stored_state_name("left_taken", "philosopher")); REQUIRE("eating" == scenario.stored_state_name("right_taken", "philosopher")); REQUIRE("thinking" == scenario.stored_state_name("stop_eating", "philosopher")); } 

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

सामान्य तौर पर, सब कुछ सरल है। लेकिन आपको दो चीजों पर ध्यान देना चाहिए।

सबसे पहले, इसके प्रोटोटाइप की तरह टेस्टिंग_नव_ टीटी, लिपटे_नव_ट, आपको एसओबीजेवी पर्यावरण को अनुकूलित करने की अनुमति देता है। हम इसका उपयोग संदेश वितरण अनुरेखण तंत्र को सक्षम करने के लिए करेंगे:

 tests::testing_env_t sobj{ [](so_5::environment_params_t & params) { params.message_delivery_tracer( so_5::msg_tracing::std_cout_tracer()); } }; 

यह तंत्र आपको संदेश वितरण प्रक्रिया को "कल्पना" करने की अनुमति देता है, जो एजेंट व्यवहार की जांच में मदद करता है (हमने पहले से ही इस बारे में अधिक विस्तार से बात की है )।

दूसरे, एजेंट दार्शनिक तुरंत नहीं बल्कि कुछ समय बाद कार्रवाई की एक श्रृंखला करता है। इसलिए, काम करना शुरू करने के लिए, एजेंट को स्वयं एक लंबित StopThinking संदेश भेजना होगा। तो यह संदेश एजेंट को कुछ मिलीसेकंड के बाद आना चाहिए। हम एक निश्चित कदम के लिए आवश्यक प्रतिबंध निर्धारित करके इंगित करते हैं:

 scenario.define_step("stop_thinking") .when( *philosopher & tests::reacts_to<philosopher_t::msg_stop_thinking>() & tests::store_state_name("philosopher") ) .constraints( tests::not_before(std::chrono::milliseconds(250)) ); 

यानी यहाँ हम कहते हैं कि हमें StopThinking के लिए Philosopher Agent की किसी भी प्रतिक्रिया में कोई दिलचस्पी नहीं है, लेकिन केवल वही जो इस चरण को संसाधित करने की शुरुआत के बाद 250ms से पहले नहीं हुआ था।

Not_before प्रकार का प्रतिबंध स्क्रिप्ट को बताता है कि निर्दिष्ट समय समाप्ति से पहले होने वाली सभी घटनाओं को अनदेखा किया जाना चाहिए।

फॉर्म का कोई प्रतिबंध नहीं है। इसके बाद, यह दूसरे तरीके से काम करता है: केवल वे घटनाएं जो तब तक होती हैं जब तक कि निर्दिष्ट समय समाप्त हो गया हो, इसे ध्यान में रखा जाता है।

Not_before और not_after बाधाओं को जोड़ा जा सकता है, उदाहरण के लिए:

 .constraints( tests::not_before(std::chrono::milliseconds(250)), tests::not_after(std::chrono::milliseconds(1250))) 

लेकिन इस मामले में, SObjectizer दिए गए मूल्यों की स्थिरता की जांच नहीं करता है।

आपने इसे लागू करने का प्रबंधन कैसे किया?

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

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

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

परीक्षण वातावरण के अंदर, प्रत्येक भेजे गए संदेश को एक विशेष लिफाफे में लपेटा जाता है। जब संदेश के साथ एक लिफाफा प्रसंस्करण के लिए एजेंट को दिया जाता है (या, इसके विपरीत, एजेंट द्वारा अस्वीकार कर दिया जाता है), तो परीक्षण परिदृश्य को इसके बारे में पता चल जाता है। लिफाफों के लिए धन्यवाद, परीक्षण स्क्रिप्ट जानता है कि क्या हो रहा है और उन क्षणों को निर्धारित कर सकता है जब स्क्रिप्ट "काम" करती है।

लेकिन कैसे एक विशेष लिफाफे में SObjectizer प्रत्येक संदेश को लपेटने के लिए?

यह एक दिलचस्प सवाल था। उन्होंने निम्नानुसार निर्णय लिया: event_queue_hook जैसी अवधारणा का आविष्कार किया गया था। यह दो विधियों के साथ एक विशेष वस्तु है - on_bind और on_unbind।

जब एक एजेंट एक विशिष्ट प्रेषणकर्ता के लिए बाध्य होता है, तो डिस्पैचर एजेंट को एक घटना Event_queue जारी करता है। इस Event_queue के माध्यम से, एजेंट के लिए अनुरोध आवश्यक कतार में आते हैं और प्रसंस्करण के लिए डिस्पैचर के लिए उपलब्ध हो जाते हैं। जब कोई एजेंट SObjectizer के अंदर चलता है, तो उसके पास event_queue का सूचक होता है। जब एक एजेंट को एक SObjectizer से हटा दिया जाता है, तो उसके सूचक को event_queue को बंद कर दिया जाता है।

इसलिए, संस्करण 5.5.24 के साथ शुरू, एजेंट, Event_queue प्राप्त होने पर, event_queue_hook के on_bind विधि को कॉल करना चाहिए। जहां एजेंट को प्राप्त सूचक को event_queue में पास करना चाहिए। और event_queue_hook प्रतिक्रिया में या तो उसी पॉइंटर या किसी अन्य पॉइंटर को वापस कर सकता है। और एजेंट को दिए गए मूल्य का उपयोग करना चाहिए।

जब किसी एजेंट को SObjectizer से हटा दिया जाता है, तो उसे event_queue_hook पर on_unbind पर कॉल करना होगा। On_unbind में, एजेंट उस मान को पास करता है जो on_bind विधि द्वारा वापस किया गया था।

यह पूरी रसोई SObjectizer के अंदर निष्पादित की जाती है और उपयोगकर्ता को इसमें से कुछ भी दिखाई नहीं देता है। और, सिद्धांत रूप में, आप इस बारे में बिल्कुल नहीं जानते होंगे। लेकिन SObjectizer का परीक्षण परिवेश, समान टेस्टिंग_env_t, बिल्कुल event_queue_hook का शोषण करता है। टेस्टिंग_नेव_ के अंदर, event_queue_hook का एक विशेष कार्यान्वयन बनाया जाता है।On_bind में यह कार्यान्वयन प्रत्येक ईवेंट_queue को एक विशेष प्रॉक्सी ऑब्जेक्ट में लपेटता है। और पहले से ही यह प्रॉक्सी ऑब्जेक्ट एजेंट को भेजे गए संदेशों को एक विशेष लिफाफे में रखता है।

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

निष्कर्ष

अंत में, मैं दो बातें कहना चाहता हूं।

सबसे पहले, हमने अपने विचार को लागू किया कि कैसे एजेंटों को SObjectizer में परीक्षण किया जा सकता है। मेरी राय है क्योंकि आसपास इतने अच्छे रोल मॉडल नहीं हैं। हमने अक्का की ओर देखा । लेकिन अक्का और सोबिजाइज़र बहुत अलग हैं जो अक्का में काम करने वाले दृष्टिकोणों को पोर्ट करते हैं। और C ++ Scala / Java नहीं है, जिसमें आत्मनिरीक्षण से संबंधित कुछ चीजें प्रतिबिंब के माध्यम से की जा सकती हैं। इसलिए मुझे एक दृष्टिकोण के साथ आना पड़ा जो कि एसओबीजेनाइज़र पर पड़ता है।

5.5.24 संस्करण में, बहुत पहले, प्रयोगात्मक कार्यान्वयन उपलब्ध हो गया। निश्चित रूप से आप बेहतर कर सकते हैं। लेकिन कैसे समझें कि क्या उपयोगी होगा और क्या बेकार कल्पनाएं हैं? दुर्भाग्य से, कुछ भी नहीं। आपको लेने और प्रयास करने की आवश्यकता है, देखें कि व्यवहार में क्या होता है।

इसलिए हमने एक न्यूनतम संस्करण बनाया, जिसे आप ले सकते हैं और आजमा सकते हैं। हम सभी के लिए क्या करने का प्रस्ताव देते हैं: कोशिश करें, प्रयोग करें और अपने छापों को हमारे साथ साझा करें। आपको क्या पसंद आया, आपको क्या पसंद नहीं आया? शायद कुछ याद आ रहा है?

दूसरे, 2017 की शुरुआत में कहे गए शब्द और भी अधिक प्रासंगिक हो गए :

… , , , . - — . . . : , .

, , , — , .

इसलिए, उन लोगों के लिए मेरी सलाह जो एक तैयार अभिनेता ढांचे की तलाश कर रहे हैं: न केवल विचारों की मौलिकता और उदाहरणों की सुंदरता पर ध्यान दें। सभी प्रकार की सहायक चीजों को भी देखें जो आपको यह पता लगाने में मदद करेंगी कि आपके आवेदन में क्या हो रहा है: उदाहरण के लिए, पता करें कि कितने कलाकार अभी अंदर हैं, उनकी कतार के आकार क्या हैं, यदि संदेश प्राप्तकर्ता तक नहीं पहुंचता है, तो यह कहां जाता है ... यदि फ्रेमवर्क करता है ऐसा कुछ प्रदान करता है, यह आपके लिए आसान होगा। यदि ऐसा नहीं होता है, तो आपके पास अधिक काम होगा।

उपरोक्त सभी और भी अधिक महत्वपूर्ण है जब यह परीक्षण अभिनेताओं के लिए आता है। इसलिए, जब अपने लिए एक अभिनेता ढांचा चुनते हैं, तो ध्यान दें कि इसमें क्या है और क्या नहीं है। उदाहरण के लिए, परीक्षण को आसान बनाने के लिए हमारे पास पहले से ही हमारे टूलकिट में है :)