Adjust paths, see #2437

This commit is contained in:
Patrik Nordwall 2012-09-22 09:21:21 +02:00
parent d2747df451
commit aa5f6154c8
2 changed files with 9 additions and 9 deletions

View file

@ -400,20 +400,20 @@ How to Test
:ref:`multi-node-testing` is useful for testing cluster applications. :ref:`multi-node-testing` is useful for testing cluster applications.
Set up your project according to the instructions in :ref:`multi-node-testing` and :ref:`multi_jvm_testing`, i.e. Set up your project according to the instructions in :ref:`multi-node-testing` and :ref:`multi-jvm-testing`, i.e.
add the ``sbt-multi-jvm`` plugin and the dependency to ``akka-remote-tests-experimental``. add the ``sbt-multi-jvm`` plugin and the dependency to ``akka-remote-tests-experimental``.
First, as described in :ref:`multi-node-testing`, we need some scaffolding to configure the ``MultiNodeSpec``. First, as described in :ref:`multi-node-testing`, we need some scaffolding to configure the ``MultiNodeSpec``.
Define the participating roles and their :ref:`cluster_configuration` in an object extending ``MultiNodeConfig``: Define the participating roles and their :ref:`cluster_configuration` in an object extending ``MultiNodeConfig``:
.. includecode:: ../../akka-samples/akka-sample-cluster/src/multi-jvm/scala/sample/cluster/stats/StatsSampleSpec.scala .. includecode:: ../../../akka-samples/akka-sample-cluster/src/multi-jvm/scala/sample/cluster/stats/StatsSampleSpec.scala
:include: MultiNodeConfig :include: MultiNodeConfig
:exclude: router-lookup-config :exclude: router-lookup-config
Define one concrete test class for each role/node. These will be instantiated on the different nodes (JVMs). They can be Define one concrete test class for each role/node. These will be instantiated on the different nodes (JVMs). They can be
implemented differently, but often they are the same and extend an abstract test class, as illustrated here. implemented differently, but often they are the same and extend an abstract test class, as illustrated here.
.. includecode:: ../../akka-samples/akka-sample-cluster/src/multi-jvm/scala/sample/cluster/stats/StatsSampleSpec.scala#concrete-tests .. includecode:: ../../../akka-samples/akka-sample-cluster/src/multi-jvm/scala/sample/cluster/stats/StatsSampleSpec.scala#concrete-tests
Note the naming convention of these classes. The name of the classes must end with ``MultiJvmNode1``, ``MultiJvmNode2`` Note the naming convention of these classes. The name of the classes must end with ``MultiJvmNode1``, ``MultiJvmNode2``
and so on. It's possible to define another suffix to be used by the ``sbt-multi-jvm``, but the default should be and so on. It's possible to define another suffix to be used by the ``sbt-multi-jvm``, but the default should be
@ -421,18 +421,18 @@ fine in most cases.
Then the abstract ``MultiNodeSpec``, which takes the ``MultiNodeConfig`` as constructor parameter. Then the abstract ``MultiNodeSpec``, which takes the ``MultiNodeConfig`` as constructor parameter.
.. includecode:: ../../akka-samples/akka-sample-cluster/src/multi-jvm/scala/sample/cluster/stats/StatsSampleSpec.scala#abstract-test .. includecode:: ../../../akka-samples/akka-sample-cluster/src/multi-jvm/scala/sample/cluster/stats/StatsSampleSpec.scala#abstract-test
Most of this can of course be extracted to a separate trait to avoid repeating this in all your tests. Most of this can of course be extracted to a separate trait to avoid repeating this in all your tests.
Typically you begin your test by starting up the cluster and let the members join, and create some actors. Typically you begin your test by starting up the cluster and let the members join, and create some actors.
That can be done like this: That can be done like this:
.. includecode:: ../../akka-samples/akka-sample-cluster/src/multi-jvm/scala/sample/cluster/stats/StatsSampleSpec.scala#startup-cluster .. includecode:: ../../../akka-samples/akka-sample-cluster/src/multi-jvm/scala/sample/cluster/stats/StatsSampleSpec.scala#startup-cluster
From the test you interact with the cluster using the ``Cluster`` extension, e.g. ``join``. From the test you interact with the cluster using the ``Cluster`` extension, e.g. ``join``.
.. includecode:: ../../akka-samples/akka-sample-cluster/src/multi-jvm/scala/sample/cluster/stats/StatsSampleSpec.scala#join .. includecode:: ../../../akka-samples/akka-sample-cluster/src/multi-jvm/scala/sample/cluster/stats/StatsSampleSpec.scala#join
Notice how the `testActor` from :ref:`testkit <akka-testkit>` is added as :ref:`subscriber <cluster_subscriber>` Notice how the `testActor` from :ref:`testkit <akka-testkit>` is added as :ref:`subscriber <cluster_subscriber>`
to cluster changes and then waiting for certain events, such as in this case all members becoming 'Up'. to cluster changes and then waiting for certain events, such as in this case all members becoming 'Up'.
@ -440,7 +440,7 @@ to cluster changes and then waiting for certain events, such as in this case all
The above code was running for all roles (JVMs). ``runOn`` is a convenient utility to declare that a certain block The above code was running for all roles (JVMs). ``runOn`` is a convenient utility to declare that a certain block
of code should only run for a specific role. of code should only run for a specific role.
.. includecode:: ../../akka-samples/akka-sample-cluster/src/multi-jvm/scala/sample/cluster/stats/StatsSampleSpec.scala#test-statsService .. includecode:: ../../../akka-samples/akka-sample-cluster/src/multi-jvm/scala/sample/cluster/stats/StatsSampleSpec.scala#test-statsService
Once again we take advantage of the facilities in :ref:`testkit <akka-testkit>` to verify expected behavior. Once again we take advantage of the facilities in :ref:`testkit <akka-testkit>` to verify expected behavior.
Here using ``testActor`` as sender (via ``ImplicitSender``) and verifing the reply with ``expectMsgPF``. Here using ``testActor`` as sender (via ``ImplicitSender``) and verifing the reply with ``expectMsgPF``.
@ -448,7 +448,7 @@ Here using ``testActor`` as sender (via ``ImplicitSender``) and verifing the rep
In the above code you can see ``node(third)``, which is useful facility to get the root actor reference of In the above code you can see ``node(third)``, which is useful facility to get the root actor reference of
the actor system for a specific role. This can also be used to grab the ``akka.actor.Address`` of that node. the actor system for a specific role. This can also be used to grab the ``akka.actor.Address`` of that node.
.. includecode:: ../../akka-samples/akka-sample-cluster/src/multi-jvm/scala/sample/cluster/stats/StatsSampleSpec.scala#addresses .. includecode:: ../../../akka-samples/akka-sample-cluster/src/multi-jvm/scala/sample/cluster/stats/StatsSampleSpec.scala#addresses
.. _cluster_jmx: .. _cluster_jmx:

View file

@ -21,7 +21,7 @@ to tell if the module has a maintainer that can take the responsibility
of the module over time. of the module over time.
.. toctree:: .. toctree::
:maxdepth: 2 :maxdepth: 1
../cluster/index ../cluster/index
../dev/multi-node-testing ../dev/multi-node-testing