you
welcome to section 6 testing actors in
the previous section working with akka
cluster we were introduced to the occur
Custer and touched upon topics such as
remote actor rooting on the cluster
cluster sharding and cluster singleton
in this section we will shift our focus
to testing different aspects of a cur we
will test our actors parent-child
relationships and finite state machines
finally we will take a look at multimode
tests let's start with the first video
how to test an actor in this video we
will take a look at the different styles
to test the actor and we will start with
coding acha comes with a dedicated
module for supporting tests the akka
test kit let's add the aqha test kit
module and scarlett s to our
dependencies here is the counter actor
which handles the messages increment
decrement and get count and has a count
variable we want to implement our tests
for this actor let's create a counter
spec class that extends the test kit
class which gives us the basic tools we
need to work with actors this includes
access to the actor system as well as
helper methods for dealing with
responses from actors under test we will
be using Scala test in this video
however it's possible to test occur
using different testing frameworks the
test kit provided by acha is test
framework independent in case of Scala
test we need to extend the flat spec
like trait to get the general test
syntax available before and after all to
be able to hook into the Suites
lifecycle events and we'll use the must
matches to actually write our assertions
using the X must do something style
first let's shut down the actor system
after all the tests finish for this
override the after all method we will
use the shutdown actor system method
from test kit as our actor system was
created by the test kit called system
now let's add our test unit
first let's define our sender actor that
will send messages for our counter actor
we will use test probes which allows us
to send messages and expect response
messages next let's define running an
instance from our actor send an
increment message and then get the count
message now our sender should receive
the response of the getcount message
test probes provide some methods that
help us to expect the messages let's use
expect message type which expects a
message of a specific type our response
should be int if the sender receives a
message with another type this
expectation will fail finally let's
assert on the value of the state the
state must be equal to 1 let's run
great it passes let's implement a test
unit for increment messages only we do
not want to set up a test probe each
time in the test we can instead use the
implicit senders trait which makes the
test get able to receive messages
directly the test kit contains the test
actor which contains expectation methods
such as test probe when we mix with
implicit sender this test actor uses as
a sender for any message in tests so
let's define a running instance of a
counter
and send an increment message for it
when the counter actor receives an
increment message it just changes the
count and doesn't send a response to the
sender so let's expect that we didn't
receive messages during that one second
slot here we are using the implicit
sender let's run great it passed as well
now let's add a test unit for the
decrement message like the previous one
but we will send a decrement message and
also expect no message let's run
great now let's add a test forget count
but we will use an implicit sender and
send the getcount message only to make
sure our actor starts with zero on the
count variable so let's add an instance
of the counter send the get count
message and expect we will receive the
message containing zero let's run
excellent now let's add another test
where we will send the increment
decrement and get count messages let's
create an instance of the counter then
send to increment messages send a
decrement message and also send another
increment message now the counter actor
should contain account that equals 2 so
let's send a get count message and
expect to receive a message that
contains two let's run
excellent all tests passed at the end of
this video we implement a different unit
test for each counter actor we use the
recommended style from Acker you can
check the test documentation from here
and you'll find another style for
testing called synchronous testing which
uses test active ref but it's
potentially exposed for race conditions
and should not be used