Version 5, last updated by samira_t at September 02, 2011 21:20 UTC

This page is intended as a place at which to collect thoughts/requirements/research about the complex domain of testing actor systems. Insert or comment items as you see fit.

There is a write-up of the currently provided test facilities at the akka snapshot documentation.

As the start point, the first added features would be ported from Setac which is written for Scala actors. These features need the testing framework acts in two modes: active and passive. In the active mode, the schedule of the system (order of messages) would be controlled by the framework and in the passive mode, the schedule of the system would be observed by the framework and the events are recorded. In summary the framework should have the following features:

  1. Constraining the schedule of the system execution by providing a language to define messages and partial orders among messages
  2. Providing an appropriate language to check the state of the system when the system is stable including:
    • The state of the messages (processed, delivered, etc) and actors (started, terminated, etc) 
    • The order of the messages in the execution to see if it meets some constraints or not
    • The content of actor mail boxes        

High-Level Requirements

  1. The TestKit should allow multiple paradigms as not one size fits all.
  2. The TestKit should allow testing of existing actor systems without requiring their source code to be modified; this does not need to hold for all provided methodologies.
  3. The TestKit should support fully deterministic as well as randomized (“bug shaker”) execution and possibly others in between

Discussion Points from Scalathon

  • it should be possible to (partially) constrain invocation schedules (like Samira’s paper)
  • it should be possible to assert an ordering of a subset of the invocation schedule (i.e. throw AssertionError somehow upon violation)
  • this all should work without having to modify the system under test in any way; one possibility is to inject a “test mode” via a configuration option which changes the ActorRef factory behavior to return a special test version of ActorRef

White Box Testing

 

Unit Testing

 

Black Box Testing

 

Integration Testing

 

Full System Testing