Functional test scenarios for Actor model feature
| Task | Description | Duration | Status | Start Date | End Date | Comment |
|---|---|---|---|---|---|---|
| A | Scenario: Node actor is created when dms is onboarded | 0.5 Hrs | Done | |||
| B | Scenario: Node actor can create an allocation actor on the same machine / dms | 0.1 Hrs | Done | |||
| C | Actors are uniquely identified in the network and can see / find each other | 0.1 Hrs | Done | |||
| D | Basic actor model premises are met | 0 Hrs | Will not be fully resolved here | Only the creation of actors, identification and ability to see at least one direct peer + basic messaging will be tested by these features; sending well formatted messages / routing and private state capabilities of actors will be implemented in other features (p2p networking and method invocation) | ||
| D1 | Premise 1: actors can send messages | 0.2 Hrs | Done | The basic actor implementation checks if an actor can send a message on the level of actor interface and it is received by target actor; the payload processing is not checked here; | ||
| D2 | Premise 2 : actors can create other actors (node -> allocation; allocation -> allocation) | 0.2 Hrs | Done | (node->allocation creation is covered by task B); this premise covers the (allocation-> allocation) actor creation both on the same and different machines | ||
| D3 | Premise 3: actors can receive messages | 0.2 Hrs | Done | We check that actors can receive messages on the level of actor interface, but do not check if they are correctly processed | ||
| D4 | Premise 4: actors can have behaviours which are private to themselves and triggered only via messages (this will also be defined / tested re functionality of dynamic method dispatch / invocation) | 0 Hrs | Not is going to be resolved here |
Edited by kabir