ActorJs - Introduction ActorJs - Documentation Our offer The simulator challenge Q & A

ActorJs: an Introduction

With ActorJs you can isolate very complex connectivity-based systems. ActorJs arranges all the scenography you need so you can focus getting the right testing done.

Why is ActorJs unique?

  • It handles any environment, encapsulating the system under test:
    • Full control through separations
    • No need for traditional simulators or mock-ups of processes
  • It allows you to go beyond test and focus on making development efficient:
    • Minimal test coding – create unique building blocks incrementally, and reuse them
    • Visualization (sequence diagrams, logging, test results, specification generation)
    • Debugging
  • Every tester/developer has a local instance of the tool:
    • Just download from repo, and run
  • ActorJs is well prepared for Continuous Integration
  • Using ActorJs while developing software accelerates development
 
 
 

Act 1: Analyze

 

Testing a highly complex system that relies on multiple third-party services can be quite a challenge.

  • How do you isolate this kind of system?
  • How do you make the third-party services behave like you need them to for effective testing?
  • How do you do negative testing?

Let's look at a real-life example from telecommunications involving a mobile phone, a mobile phone operator, and IP traffic.

This is a fairly straightforward case: browsing on a mobile phone to fetch an image (some steps in the actual process are omitted here for this demonstration).

We need to test the proxy handling of the incoming and outgoing IP traffic, including a check to ensure that the mobile phone user won't be able to browse blacklisted sites. We'll call this proxy the SUT, or System Under Test.

This proxy handling is illustrated in the diagram at the right.

To make this test case possible, ActorJs will need to represent four user agents:

  • Mobile: mobile phone - Radius & Http
  • HSS: Home Subscriber Server, a user database - Diameter
  • www: web server containing the requested multimedia - Http
  • Rights: server containing the blacklisted www servers - Socket

The diagram below shows us that, behind the scenes, testing this "simple" functionality can be very complex. A simple test case will require four simulators and/or mocked-up processes. In addition, we would probably want to test different image formats, resizing and so on...Simulating all the different things we need will be time-consuming, expensive, or probably both!

 

With ActorJs, you can go beyond simulators and mock-ups to easily isolate the SUT and execute the test case – in less time and at lower cost than with traditional testing. Let's start by analyzing what we want to test.

 

Scene 1 - Connect the phone to the network

When connecting to the network, the phone sends a Radius Access Request to the SUT. The SUT then sends a Diameter User Authorization Request (UAR) to the HSS and answers are sent back to the mobile.

What do we really have to do to perform a test? In truth, not that much. All that's happening is that an Actor is sending a request and receiving a request; then an answer is sent and received. With ActorJs, this is all you have to do to determine whether the system works as intended.

 

Scene 2 - Get the content

The phone will send an HTTP Request to get the image. Then the SUT will make sure the content is not blacklisted, and will send the HTTP request to the web server. Again, responses will be sent back.

In this case we need to send one request, receive two, send two responses, and receive one response.

 

 Conclusion

This quite complex use case becomes much simpler once we understand what needs to be done. ActorJs will take care of the scenography, and if the different stacks are already available, almost nothing is left to do.

We have four user agents (mobile, HSS, web, rights server) but when breaking this down for test, we will implement five Actors. These are small pieces of code, or building blocks, that will perform the testing actions:

  • mobile - login
  • mobile - get image
  • HSS - login
  • Rights - authorize
  • www - get

Act 2: Implement

 

Once analysis is complete, it's time to prepare the five Actors for their roles. In a real test case we would probably need to do a little more than just sending and receiving messages; we might need to read test data, do verifications, and so on. Our example shows how Actors require only minimal code to send and receive the messages involved in testing the SUT.

Some Actors may already be available from previous testing. This is another strength of the ActorJs solution! You can reuse these "building blocks" as they are, or just make small changes and adapt them to the task at hand.

 
 

Actor 1: mobile login

Actor mobile login sends a Radius request and receives a Radius answer.

Actor 2: mobile get image

Actor mobile get image sends an HTTP get request and receives an HTTP response.

Actor 3: HSS login

Actor HSS login accepts a connection, receives a Diameter request and sends a Diameter answer.

Actor 4: Rights authorize

Actor Rights authorize accepts a connection, receives a Socket message and send a Socket message.

Actor 5: www get

Actor www get accepts a connection, receives an HTTP request and sends an HTTP response.

 
 

ActorJs takes care of the scenography, and the Actors require a very small amount of code to achieve the desired flow of information through the SUT. Compare this with traditional test, and it becomes clear how much easier it will be to test these complex scenarios.

For our example, ActorJs generates the following sequence diagram to describe the signaling.

 

 Act 3: Test

After implementation, we create the test cases. In ActorJs, a test case is 100% data-driven, but we still have 100% control of the code in the Actors.

A test case has three parts:

  • Actor data: Choice of Actors and their dependencies with each other. Choice of addresses used by the Actors.
  • Test data: The Actors will request the test data they need. Test data can be set on different levels, such as Actor, test-case, and general levels.
  • Verification data: The Actors will request the verification data they need.

When the first test case is done, it is easy to do more. Let's say we want to do the same test, but with different images and accept headers. All we have to do is create new test cases and change the test data. Here's an example:

 
  • TC1
    • request-uri: image.jpg
    • accept: image/jpeg
  • TC2
    • request-uri: image_big.jpg
    • accept: image/jpeg
  • TC3
    • request-uri: image_small.jpg
    • accept: image/jpeg
  • TC4
    • request-uri: image.png
    • accept: image/jpeg
  • TC5
    • request-uri: image.gif
    • accept: image/jpeg
  • TC6
    • request-uri: image.png
    • accept: image/png
  • TC7
    • request-uri: image_big.png
    • accept: image/png
  • TC8
    • request-uri: image_small.png
    • accept: image/png
  • TC9
    • request-uri: image.jpg
    • accept: image/png
  • TC10
    • request-uri: image.gif
    • accept: image/png