Description

The experience of writing and maintaining thousands of testcases over the years has lead to the following style guide for writing testcases to be as consistent and easy to maintain as possible. Many of the older testcases for GINT may not follow this standard as they haven't been refactored yet . These are suggestions. The tool does not depend on what style is used . Try to refactor older tests to use better style before copying them for another scenario.

Guidelines

Ordering of testcase parameters

Most parameters are optional, but if they are provided, order then in this way:

1. name or extension specific equivalent (like action and ext or macro and ext for example)
2. description - helpful for documenting the test, but don't bother if it is just a repeat of the name - it needs to add some meaningfully info
   
3. onlyIf
4. level
5. group
6. dependsOn, mustRunAfter, and mustRunBefore or similar
7. sleep
8. startClosure
9. inline or cmd or command generator specific parameters
10. resultClosure and successClosure
11. expected (only if error is expected)
12. data and/or output and related
13. failData
14. retry and related parameters
15. finalClosure

Spacing

Use one line for each parameter except #1 - #3 can and should be on the same line. One line per parameter makes it easy to add comments. Groovy code style should be close to your Java coding style. In our case, we use 4 space indenting and other fairly standard Java style and coding conventions and spacing.

gint.add('myGroup', [
    [name: 'test1', description: 'It is important to say what this is testing',
        level: isServerAvailable, // only run this test if the server is available
        parameters: [ // cmd generator specific parameters
            server: server,
        ], 
        data: [
            'my data',
        ],
        failData: [
            'null', // better not find a null in the output data
        ], 
    ],
    [name: 'test2', 
        dependsOn: ['test1'], // test1 must be successful before this test will be run
        parameters: [
            server: server,
        ],
        data: [ ordered: [
            'my data again',
            'then this data',
        ]],
        failData: [
            'null', // better not find a null in the output data
        ], 
        finalClosure: { testcase -> 
            ...
        }, 
    ], 
    [action: 'getProjectList', ext: 'AfterAddProject', description: 'Verify project got added',
        ...
    ], 
    [macro: 'info', ext: 'Title', description: 'Test a title on the info macro',
        ...
    ],
])
 

Using lists

1. For parameters that take either a single value or a list, use the list version even if you only have one item. This makes future additions easier. Example: data: ['my data'] instead of data: 'my data'.
2. Normally split lists with multiple entries onto separate lines. It is more readable and easier to add.
3. Always add extra comma at end. Groovy is very nice to allow unnecessary commas at the end of lists. This make maintenance easier when another item needs to be added.

Naming

• Testcases and groups should start with lowercase letter and follow similar standards to variables (camel case) names like: myTestName
• With generated testcases that are usually based on looping, often good to use dash separated names like: 'space-' + space + '-' + page 
• Avoid special characters and blanks (although they are not explicitly excluded)
• Testcase and group names share the global variable name space. Be careful to not use names already used by GINT. 

Groups

• Normally, add testcases within a group. Usually better for readability, but, makes it easier to run related tests together. Try not to have run-on groups.

  • Example: see above spacing example.

• Choose group names carefully following

  • Group and testcase names share the same name space!

  • They are all tasks for the command line.