Test

    The test framework allows the developer to redefine the authorization rules for different classes of users in a domain specific language.

    Provided some test data for a , the framework builds a graph (cycles removed) of every possibleway to navigate the test data originating from the rootable entities.

    For every collection and entity in the graph, it tests all combinations of CRUD operations - comparing the result returned from Elide with the expected resultdefined in the domain specific language. Any mismatches are reported as test failures.

    The DSL is structured as a gherkin feature file with the following elements:

    Exposed entities is a table describing which JPA entities are exposed through Elide and which of those entities are rootable.

    There will be different classes of users who have access to the system. A class of users are the set of users who share the same authorizationpermissions. Ideally, the developer should define a user for each permutation of authorization permissions they want to test.

    1.     And users
    2.       # Amalberti father
    3.       | Emmanuel |
    4.       # Bonham parents
    5.       | Mo       |

    Associated permissions is a table that defines which entities a given user class has access to. For each set of entities, it alsodefines which CRUD operations are allowed.

    1.     And associated permissions
    2.       | UserName  | EntityName | ValidIdsList            | EntityPermissions         | RestrictedReadFields  | RestrictedWriteFields |
    3.        ########### ############ ##############            ########################### ####################### #######################
    4.       | Mo        | parent     | Mo                      | Create,Read,Update        |                       | deceased              |
    5.       | Mo        | parent     | Mo's Spouse             | Create,Read,Update        | otherSpouses          | deceased              |

    UserName

    This column identifies the user class.

    EntityName

    This column identifies the JPA entity. The name must match the name exposed via Elide.

    ValidIdsList

    There is a grammar which defines the syntax for this column. In short, it can be one of the following:

    • A comma separated list of entity IDs. The IDs much match the test data in the DataStore.
    • An expression [type.collection] where type is another entity and collection is a relationship inside of type that contains elements of type EntityName. This expression semantically means: ‘If the user has any access to an entity of type type, they should have access to everything inside that entity’s collection collection.’ More concretely, this expression will get expanded to a comma separated list of IDs by first expanding type to the set of entities of type type the user class has access to. For each of these entities, it will then expand to the list of IDs contained within collection. Expressions of this type can be combined within lists of comma separated IDs.
      Aliases can also be defined to represent one or more comma separated IDs, These aliases are expanded in the grammar expression prior to parsing. Aliases are defined in the gherkin file:

    Aliases can reference other aliases.

    EntityPermissions

    Entity Permissions are the list of CRUD permissions that are allowed for the given list of entities for the given user. They should be definedas a comma separated list of the keywords ‘Create’, ‘Read’, ‘Update’, and ‘Delete’.

    RestrictedReadFields & RestrictedWriteFields

    • A comma separated list of field names.
    • The keyword [ALL] which signifies all fields.
    • The keyword [EXCLUDING] followed by a list of fields. This inverts the column to a white list of allowed fields instead of a blacklist of excluded fields.
    1.     And disabled test ids
    2.       | CreateRelation:child#5/relationships/playmates:Denied=[1,2,3] |
    3.       | CreateRelation:child#6/relationships/playmates:Denied=[3]     |

    If you want to disable a test from running, you can do so by adding ‘name’ of the test to this list. The ‘name’ of the tests are displayedin the output of test framework executions.

    A full example of the configuration DSL can be found

    Using the framework can be broken down into the following steps:

    • Create a feature file using the described DSL.
    • Write a Java program that does the following:
      • Create a DataStore
      • Create test data.
      • Create a UserFactory.

    Given that the goal of the test framework is limited to testing authorization code (security check logic), the DataStore used to furnish test datashould be orthogonal to the correctness of the tests.

    The ValidationDriver takes an optional boolean parameter () that will fail the test execution if there is no test datafor any entity exposed via Elide. If this parameter is not set, it will simply log the absence of test data.