Version 5

    Guvnor is to support simulation and testing (see




    This document captures the principle requirements and components.





    A new asset type is required to represent a simulation test. The asset can be authored and executed within Guvnor.


    A new screen(s) is required to visualise and define a timeline (consisting of one or more paths, each with one or more steps, each with one or more commands).

    Note: due to GWT restrictions when compiling to JavaScript, a GWT specific Path, Step and Command model has been created.


    There are some GWT-enabled "time-line" libraries available:


    There is no requirement to convert existing Test Scenarios to the newer Simulation Tool.



    Test data


    Commands can be composed and values defined using pluggable bean builders (for which there would be one per existing simulation command. Pluggable to support the addition of future commands).

        Note: Some commands are implicit, such create a knowledge base, builder and session for the chosen package "mortgages".

    Note: the GWT user commands map to multiple existing simulation commands. For example asserting that a rule has fired. The implementation deals with this.


    Bean builders facilitate defining data for a single command.



    Bulk test data-entry


    In addition to defining data for individual Commands it should be possible to define data in bulk.


    Bulk data for a simulation is effectively a sparsley populated cube of data, consisting of vertices for "Fact-Fields", "Fact-Field-Values" and "Command".


    Bulk data entry should be possible in a tabular form where columns define one axis of the foregoing cube and rows another.


    For example: columns represent "Commands" and rows represent "Fact-Fields". The values in the table therefore represent "Fact-Field-Values".


                  | InsertFactPerson    | InsetFactVehicle    | QueryFactCoverage


    Person.age    | 18                  |                     |

    Vehicle.make  |                     | BMW                 |

    Vehicle.model |                     | M3                  |

    Cover.level   |                     |                     | LOW-COVER


    Another example: columns represent "Fact-Fields" and rows represent "Fact-Field-Values". The values in the table therefore represent "Commands".


                  | Person.age        | Vehicle.make        | Vehicle.model      | Cover.level


    18            | InsertFactPerson  |                     |                    |

    BMW           |                   | InsertFactVehicle   |                    |

    M3            |                   |                     | InsertFactVehicle  |

    LOW-COVER     |                   |                     |                    | QueryFactCoverage


    Data can be either entered manually, uploaded (consider CSV and XLS) or retrieved from a remote source (consider JSON, REST).





    Overlaying bulk data


    Data entered manually and individually for each Command's definition clearly has an explicit corrolation with the simulation step to which it relates.


    Bulk data's corrolation to the simulation steps to which individual components relate is much looser.


    A mechanism must be provided for batch data to be mapped to the simulation defintion. Furthermore, once a mapping has been created, it should be possible for different sets of bulk data to be overlaid on a simulation definition.


    Overlaying Paths


    A single simulation can be comprised of one or more Paths.


    It should be possible to combine different combinations of Paths. Thus it might be advantageous to consider authoring as a single Path, whereas runtime as a combination of selected paths.





    Some Commands may result in a bound Fact or Field.


    The simulation editor should be capable of allowing subsequent Commands to reference a bound Fact or Field.





    The following modes of execution should be supported:

    • Fire and forget: like JUnit, results of test assertions gathered and displayed as simulation runs.
    • Walk-through: like JUnit in debug mode, with break-points on Path's Steps' Commands.
      • Parameter \ state viewer during debug mode:-
      • View Drools Expert Agenda
      • View Drools Expert Audit (Agenda Listener derieved)


    Extra requirements


    1. The timeline needs 2 views: a page view and a global view. The page view shows a zoomed in portion of the timeline and the global view show the entire timeline.