アクターは、共有、共有の可変状態を回避することにより、マルチスレッドプログラミングを簡素化します。各アクターは、誰にも見えない独自のデータを所有しています。アクターは、非同期メッセージを介してのみ対話します。したがって、アクターを使用する際のレースやデッドロックという形でのマルチスレッドの最も恐ろしい恐怖はひどいものではありません（ただし、アクターは問題を抱えていますが、今はそうではありません）。

一般に、アクターを使用したマルチスレッドアプリケーションの作成は簡単で楽しいものです。俳優自身が簡単かつ自然に書かれているためです。アクターコードの記述が仕事の最も簡単な部分であると言うことさえできます。しかし、俳優が書かれたとき、非常に良い質問が生じます：「その作品の正確さをチェックする方法は？」

質問は本当にとても良いです。一般的に俳優について、特にSObjectizerについて話すとき、私たちは定期的に彼に尋ねられます。そして最近まで、この質問には一般的な用語でしか答えられませんでした。

しかし、バージョン5.5.24がリリースされ、アクターのユニットテストの実験的サポートが登場しました。そして、この記事では、それが何であるか、どのように使用するか、どのように実装されているかについてお話します。

アクターテストはどのように見えますか？

SObjectizerの新機能について、いくつかの例で検討し、何が何であるかを伝えます。議論された例のソースコードは、このリポジトリにあります。

ストーリー全体を通して、「俳優」と「エージェント」という用語は同じ意味で使用されます。それらは同じものを指定しますが、SObjectizerでは「エージェント」という用語が歴史的に使用されているため、さらに「エージェント」がより頻繁に使用されます。

PingerとPongerを使用した最も簡単な例

アクターPingerとPongerの例は、おそらくアクターフレームワークの最も一般的な例です。古典とも言えます。それで、もしそうなら、古典から始めましょう。

そのため、作業の開始時にPongerエージェントにPingメッセージを送信するPingerエージェントがいます。 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; } };

私たちのタスクは、これらのエージェントをSObjectizerに登録すると、PongerがPingメッセージを受信し、Pingerが応答としてPongメッセージを受信することを検証するテストを作成することです。

OK 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 :: Experimental :: testing名前空間で説明されていますが、このような長い名前を繰り返さないために、短くて便利なエイリアスを導入します。

 namespace tests = so_5::experimental::testing;

以下は、単一のテストケースの説明です（ここではこれ以上必要ありません）。

テストケース内には、いくつかの重要なポイントがあります。

まず、これはSObjectizerの特別なテスト環境の作成と起動です。

 tests::testing_env_t sobj;

この環境がないと、エージェントの「テスト実行」は完了できませんが、これについては少し後で説明します。

testing_env_tクラスは、SObjectizerのwrapped_env_tクラスに非常に似ています。同様に、SObjectizerはコンストラクターで開始し、デストラクターで停止します。そのため、テストを記述するときに、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では、スクリプトのステップが分岐やループなしで厳密に連続して「動作」することを意味します。

エージェントのテストを作成することは、実行する必要があるテストシナリオの定義です。つまりテストスクリプトのすべての手順は、最初から最後まで機能するはずです。

したがって、テストケースでは、2段階のシナリオを定義します。最初のステップでは、PongerエージェントがPingメッセージを受信して処理することを確認します。

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

2番目のステップでは、PingerエージェントがPongメッセージを受信することを確認します。

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

これらの2つの手順はテストケースに十分であるため、決定後、スクリプトの実行に進みます。スクリプトを実行し、100ミリ秒以内に機能するようにします。

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

2つのエージェントがメッセージを交換するには、100ミリ秒で十分です（Travis CIの場合のように、テストが非常に遅い仮想マシン内で実行される場合でも）。さて、エージェントの記述を間違えたり、テストスクリプトを誤って記述した場合、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のエージェントは、メッセージを交換し、introduce_coopから戻る前に作業を完了することができます（マルチスレッドの奇跡はそのようなものです）。しかし、testing_env_tのおかげで作成されたテスト環境内では、これは起こりません。PingerとPongerエージェントは、テストスクリプトを実行するまで辛抱強く待ちます。これはどのように起こりますか？

実際、テスト環境内では、エージェントは凍結状態にあるように見えます。つまり登録後、それらはSObjectizerに存在しますが、メッセージを処理することはできません。したがって、テストスクリプトが実行される前に、エージェントに対してso_evt_start（）も呼び出されません。

run_for（）メソッドを使用してテストスクリプトを実行すると、テストスクリプトはまずすべての凍結エージェントを解凍します。そして、スクリプトは、エージェントに何が起こるかに関する通知をSObjectizerから受け取り始めます。たとえば、PongerエージェントはPingメッセージを受信し、Pongerエージェントはメッセージを処理しましたが、拒否しませんでした。

このような通知がテストスクリプトに届き始めると、スクリプトは通知を最初のステップまで「試行」しようとします。それで、PongerがPingを受信して処理したという通知があります-それは私たちにとって興味深いものですか？ステップの説明がまさにそれを言っているので、それが面白いことがわかります：PongerがPingに反応するとき、それは動作します。コードにあるもの：

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

OK したがって、最初のステップは機能し、次のステップに進みます。

次に、エージェントピンガーがポンに反応したという通知が来ます。そして、これは第2ステップが機能するために必要なものです。

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

OK 2番目のステップは機能しましたが、他に何かありますか？いやつまり、テストスクリプト全体が完了し、run_for（）から制御を返すことができます。

ここでは、原則として、テストスクリプトの動作方法を説明します。実際、すべてがやや複雑ですが、より複雑な例を検討する際には、より複雑な側面に触れます。

食事の哲学者の例

テストエージェントのより複雑な例は、よく知られているタスク「哲学者の食事」の解決に見ることができます。アクターにとって、この問題はいくつかの方法で解決できます。次に、最も些細な解決策を検討します。俳優と哲学者の両方が、哲学者が戦わなければならない俳優の形で表されます。各哲学者はしばらく考えてから、左側の分岐点をとろうとします。これが成功した場合、彼は右側の分岐を試みます。これが成功した場合、哲学者はしばらく食べ、その後フォークを置いて考え始めます。右側のプラグを取ることができなかった場合（つまり、別の哲学者が取った）、哲学者は左側のプラグを返し、しばらく考えます。つまりこれは、哲学者の中にはあまりにも長く飢えているかもしれないという意味で良い解決策ではありません。しかし、それは非常に簡単です。また、エージェントをテストする能力を実証する範囲があります。

ForkおよびPhilosopherエージェントの実装を含むソースコードは、ここで見つけることができます。記事では、スペースを節約するためにそれらを検討しません。

フォークのテスト

エージェントフォークの食事哲学者からのエージェントの最初のテストを作成します。

このエージェントは、単純なスキームに従って機能します。彼には2つの状態があります：FreeとTaken。エージェントがFree状態の場合、エージェントはTakeメッセージに応答します。この場合、エージェントはTaken状態に入り、Taken応答メッセージで応答します。

エージェントがTaken状態にあるとき、Takeメッセージに対して異なる反応をします。エージェントの状態は変化せず、Busyは応答メッセージとして送信されます。また、Taken状態では、エージェントはPutメッセージに応答します。エージェントはFree状態に戻ります。

Free状態では、Putメッセージは無視されます。

次のテストケースを使用して、これをテストします。

 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")); }

たくさんのコードがあるので、すでに明確になっているはずのそれらのフラグメントをスキップして、部分的にそれを扱います。

ここで最初に必要なことは、本当の哲学者エージェントを置き換えることです。 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>) {}); } };

次に、ForkエージェントとPseudoPhilospherエージェントからコラボレーションを作成し、テストケースの内容の決定を開始します。

スクリプトの最初のステップは、Free状態（およびこれが初期状態）にあるForkがPutメッセージに応答しないことを確認することです。このチェックの記述方法は次のとおりです。

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

最初に注目されるのは、インパクト構造です。

エージェントForkは自分で何もせず、着信メッセージにのみ反応するため、彼女が必要です。したがって、誰かがエージェントにメッセージを送信する必要があります。しかし、誰ですか？

そして、ここにスクリプトのステップがあり、インパクトを通してそれを送ります。実際、影響は通常の送信機能に類似しています（形式は同じです）。

さて、スクリプトステップ自体が影響を通じてメッセージを送信します。しかし、いつ彼はそれをしますか？

そして、彼に順番が来たら彼はそれをするでしょう。つまりスクリプトのステップが最初の場合、run_forを入力した直後に影響が実行されます。スクリプトのステップが最初ではない場合、前のステップが機能するとすぐに影響が実行され、スクリプトは次のステップの処理に進みます。

ここで説明する必要がある2番目のことは、呼び出し無視です。このヘルパー関数は、エージェントがメッセージの処理を開始するとステップがトリガーされることを示しています。つまりこの場合、ForkエージェントはPutメッセージの処理を拒否する必要があります。

テストシナリオのもう1つのステップをさらに詳しく考えてみましょう。

 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>());

まず、ここではwhenではなくwhen_allが表示されます。これは、ステップをトリガーするには、いくつかの条件を一度に満たす必要があるためです。フォークエージェントはTakeを処理する必要があります。そして、哲学者はTakenの応答を処理する必要があります。したがって、whenではなくwhen_allを記述します。ところで、when_anyもありますが、今日検討した例では、彼とは会いません。

第二に、テイク処理の後、フォークエージェントがテイク状態になっていることを確認する必要もあります。検証は次のように行います。まず、ForkエージェントがTakeの処理を終了するとすぐに、タグタグ「fork」を使用して現在の状態の名前を保存する必要があることを示します。この構造は、エージェントの状態名を保持するだけです。

 & tests::store_state_name("fork")

そして、スクリプトが正常に完了したら、この保存された名前を確認します。

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

つまりスクリプトに問い合わせます。take_when_freeという名前のステップのforkタグで保存された名前を指定し、その名前を期待される値と比較します。

ここで、おそらく、Forkエージェントのテストケースで注意できることはすべてです。読者に質問がある場合は、コメントで質問してください。喜んでお答えします。

哲学者のための成功したスクリプトテスト

哲学者エージェントについては、1つのテストケースのみを検討します-哲学者がフォークを食べて食べることができる場合。

このテストケースは次のようになります。

 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")); }

かなりボリュームがありますが、些細なことです。最初に、哲学者が思考を終了し、食物の準備を始めたことを確認します。次に、彼が左のフォークをとろうとしたことを確認します。次に、彼は右のフォークを取るようにしてください。それから彼はこの活動を食べてやめるべきです。その後、彼は両方のフォークを取らなければなりません。

一般的に、すべては簡単です。ただし、次の2つのことに注意する必要があります。

最初に、testing_env_tクラスは、そのプロトタイプであるwrapped_env_tと同様に、SObjectizer Environmentをカスタマイズできます。これを使用して、メッセージ配信トレースメカニズムを有効にします。

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

このメカニズムにより、メッセージ配信のプロセスを「視覚化」することができます。これにより、エージェントの動作を処理するのに役立ちます（これについては既に詳しく説明しました）。

次に、エージェントPhilosopherはすぐにではなく、しばらくしてから一連のアクションを実行します。したがって、動作を開始するには、エージェントは保留中の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への応答には関心がなく、このステップの処理開始から250ms以内に発生した応答にのみ関心があると言います。

not_beforeタイプの制限は、指定されたタイムアウトの期限が切れる前に発生するすべてのイベントを無視する必要があることをスクリプトに示します。

また、not_afterという形式の制限もあります。逆の方法で機能します。指定されたタイムアウトが期限切れになるまで発生するイベントのみが考慮されます。

not_before制約とnot_after制約は組み合わせることができます。次に例を示します。

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

ただし、この場合、SObjectizerは指定された値の整合性をチェックしません。

どうやってこれを実装しましたか？

どのようにすべてが機能するようになったかについて、いくつかの言葉を述べたいと思います。実際、概して、「原理的にエージェントをテストする方法」という1つの大きなイデオロギーの問題に直面しました。

そして、テストのイデオロギーに関して、あなたが好きなように投げ出すことができるなら、状況は実装に関してより複雑でした。まず、SObjectizerの内部を根本的に変更する必要のないソリューションを見つける必要がありました。そして、第二に、それは予見可能な非常に望ましい短期間で実装できるソリューションであると想定されていました。

竹を吸うという困難なプロセスの結果として、解決策が見つかりました。このため、実際には、SObjectizerの通常の動作に1つの小さなイノベーションのみを導入する必要がありました。そして、ソリューションの基本は、メッセージのエンベロープメカニズムです。これは、バージョン5.5.23で追加されたもので、既に説明しました。

テスト環境内では、送信された各メッセージは特別なエンベロープでラップされます。メッセージを含むエンベロープが処理のためにエージェントに渡される（または、逆にエージェントによって拒否される）と、テストシナリオはこれを認識します。エンベロープのおかげで、テストスクリプトは何が起こっているかを把握し、スクリプトが「動作」するステップを判断できます。

しかし、SObjectizerに各メッセージを特別なエンベロープでラップさせる方法は？

それは興味深い質問でした。彼は次のように決定しました。event_queue_hookのようなものが発明されました。これは、on_bindとon_unbindの2つのメソッドを持つ特別なオブジェクトです。

エージェントが特定のディスパッチャにバインドされると、ディスパッチャはエージェント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内で実行され、ユーザーには何も表示されません。そして、原則として、あなたはこれについて全く知らないかもしれません。ただし、同じtesting_env_tであるSObjectizerのテスト環境は、event_queue_hookを正確に活用します。 testing_env_t内に、event_queue_hookの特別な実装が作成されます。on_bindのこの実装は、各event_queueを特別なプロキシオブジェクトにラップします。そして、すでにこのプロキシオブジェクトは、エージェントに送信されたメッセージを特別なエンベロープに入れます。

しかし、それだけではありません。テスト環境では、エージェントを凍結する必要があることを思い出してください。これは、前述のプロキシオブジェクトを通じても実装されます。テストスクリプトが実行されていない間、プロキシオブジェクトは自宅のエージェントに送信されたメッセージを保存します。ただし、スクリプトが実行されると、プロキシオブジェクトは以前に蓄積されたすべてのメッセージをエージェントの現在のメッセージキューに転送します。

おわりに

結論として、2つのことを言いたいと思います。

最初に、SObjectizerでエージェントをテストする方法に関するビューを実装しました。私の意見は、良いロールモデルがあまり多くないからです。私たちは、方向に見えたAkka.Testing。ただし、AkkaとSObjectizerはあまりにも異なるため、Akkaで機能するアプローチをSObjectizerに移植することはできません。また、C ++はScala / Javaではありません。Scalaでは、内省に関連するいくつかのことをリフレクションによって実行できます。そのため、SObjectizerに当てはまるアプローチを考え出す必要がありました。

バージョン5.5.24では、最初の実験的な実装が利用可能になりました。きっとあなたはもっと良くできるでしょう。しかし、何が有用であり、何が役に立たない空想であるかを理解する方法は？残念ながら、方法はありません。実際に何が起こるかを見て、試してみる必要があります。

そこで、私たちはあなたが試してみることができる最小限のバージョンを作りました。皆のために私たちが提案すること：あなたの印象を試してみて、私たちと共有してください。何が好きで、何が好きではなかったのですか？たぶん何かが欠けていますか？

第二に、2017年の初めに言われた言葉がさらに関連するようになりました。

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

, , , — , .

したがって、既成のアクターフレームワークを探している人への私のアドバイス：アイデアの独創性と例の美しさだけでなく注意を払ってください。また、アプリケーションで何が起こっているのかを把握するのに役立つあらゆる種類の補助的なものも見てください。たとえば、現在内部にいるアクタの数、キューのサイズ、メッセージが受信者に届かない場合、どこに行くのかを調べるには...そのようなものを提供し、それはあなたのために簡単になります。そうでない場合は、さらに作業が必要になります。

アクターのテストに関しては、上記のすべてがさらに重要です。したがって、アクターフレームワークを自分で選択するときは、その中にあるものとそうでないものに注意してください。たとえば、テストを簡素化するためのツールキットがすでにあります:)

アクターの単体テストを書く方法は？ SObjectizerのアプローチ