Opening model editor for user's project: go to My projects > click on project name.
Opening model editor for team project: go to My projects > go to left panel > go to My team projects > click on project name.
Main parts of the editor:
Main menu contains the following items:
File menu contains the following items:
Edit menu contains the following items:
View menu contains the following items:
Main toolbar contains the following icons:
Context menu is available in model explorer. It displays operations:
Displaying context menu: move mouse over node > mouse right click.
Model can be viewed in two modes:
Java mode requires Java syntax and Java data types when defining some nodes of the model. Simple can be used by non programmers. This mode uses general types like Number, Text, Logical.
Switching to Simple view mode: go to Main menu > go to View menu > select "Simple" option.
Switching to Java view mode: to to Main menu > go to View menu > select "Java" option.
In Simple view mode:
In Java view
Model editor has two edit modes: "Edit" and "Read only".
User will be limited to Read only mode in the following situations:
ecFeed has the following node types:
Root is on top of project structure. Its only property is name - label "Model name". Model name cannot be edited in model editor.
It can have the following child nodes:
Child nodes are displayed in model tree under the root node, and also in properties window, in sections "Classes" and "Global parameters".
Class node is a child of root node. It groups test functions. The properties of class node are:
Class nodes can have the following child nodes:
Method node is a child of class node. It represents test function which will be run on tested system.
The only property of method node is its name.
Method can have the following child nodes:
Method parameter node is a child of:
It represents one parameter of test function.
It has the following properties:
Method parameters can have the following child nodes:
Available parameter types in Java view mode are:
Available parameter types in Simple view mode are:
It is also possible to define user types. User type is a text for example: DocumentType. User types are not randomized and their values are translated to text.
If a parameter is used multiple times in various methods, it can be placed under root node or class node.
In this case it called a global parameter.
Global parameters placed under root node can be accessed everywhere in model.
Global parameters placed under class node an be accessed by methods of this class only.
In order to use global parameter in functions, checkbox "Linked" in the properties of the parameters should be checked. Also one of available global parameters should be selected.
The value of an expected parameter is calculated by system during test data generation process.
First system takes source data from generated test case. Then the value is calculated with the use of logic conditions - constraints (described later), Next the calculated value is placed in the test case, at position of the expected parameter.
Calculated expected value can be used in testing function to check if the response of tested system matches expected value.
Choices represent subsets of all possible parameter values. A choice has a name and value. For example for a parameter named "familyName" of type String/Text we could have the following choices and values: short (Smith), long single word (Rockefeller), long complex (Mendhelsson-Bartholdy), two words (van Beethoven), more than two words (van der Sar), invalid ($@1%&*).
In Java view mode. choices can have also symbolic values which depend on type of method parameter:
Special values can be selected from combo box.
In many cases user is not interested in a concrete value, but rather in range of values. EcFeed supports this case by so called randomized choices. Values of randomized choices are not defined until the test is executed or exported (described later).
In order to define a randomized, numeric choice user should enter range of values instead of single value.
Example: choice name: adult, range of values: 18-120
Randomized choices for parameters of String type can be defined with the use of pattern.
The pattern uses regular expression syntax.
Example: drivers license ([A-Z]{1}[0-9]{7})
With randomized choices user should avoid defining numeric ranges which overlap. Then the result of evaluation of constraints (described later) would be ambiguous.
For example:
Constraint can evaluate to false if randomly generated values are for example 1 > 5. Or it can evaluate to true in case: 6 > 5.
Grouping of choices is used to simplify definition of logic conditions used in data generation - constraints (described later). For example first names could be grouped: male (John, Alexander, Jean Pierre), female (Eva, Margaret, Mary Jane).
Creating hierarchical groups of choices: select parameter firstName > add choice "male" > select choice "male" > add choice "John" etc.
Choices which have children choice nodes are called ABSTRACT. Abstract choices have no value.
User can create more then one level of hierarchy. Abstract choices can have children choices which are also abstract.
Sometimes another grouping of choices is needed. For example first names could be grouped as "one word" and "two words". Choice label can be used for this purpose. Choice labels can also be used in constraints.
Adding choice label: select choice > in properties window click "Add label" button > type label.
Constraints are logic conditions (sometimes quite complex) which are used during test data generation process to:
During data generation process generates constraints are evaluated for each test case in order of definition.
Constraints can be defined in constraint editor.
Combo-box "Constraint type" in properties window defines type of a constraint.
There are three types of constraints:
Invariant constraint is a filtering constraint. It has one logic condition. If this condition evaluates to false, the test case is excluded from generation results.
For example (as on picture above) if user wants to exclude people of age from 1-17, and 66-120, the defined condition would be: age=working[choice].
Implication constraint has two logic conditions: precondition and postcondition. Precondition is a preliminary filter, which qualifies test cases for further evaluation. If precondition evaluates to false, evaluation of postcondition is skipped and the test case is not excluded from generation results (constraint evaluates to true). If precondition evaluates to true, then postcondition is evaluated. If postcondition evaluates to false, the test case is excluded from generation results.
Assigning constraint does not filter test cases. Instead it assigns a value to an expected parameter. Assignments to multiple parameters is also possible. Assigning constraint has one logic condition and assignments window. If logic condition evaluates to true, the assignments are made. Otherwise the default value of expected parameter is assigned.
Statement editor is located at the bottom line of constraint editor. It allows user to define basic logic conditions.
The editor contains three fields:
Left operand is always the name of one of parameters which are not marked as expected.
Value for the right operand is one of:
Complex logical conditions may be created using simple statements and logical operators.
Logical operators are AND, OR. They can be nested.
In constraint editor, logical operators stand before statements, to which they refer.
Data generation takes model with constraints as source and creates a list of test cases.
A test case contains:
Generated test cases contain combinations of choices assigned to method parameters.
Their order is the same as parameters in method: choice from parameter 1, choice from parameter 2, etc.
Expected parameters are excluded from these combinations. Their values result from default value of expected parameter or evaluation of assignment constraints.
Expected values are displayed as @expected[15] (longer convention) or [e]15 (in model explorer).
Generated test cases do not strictly belong to data model.
However they are placed under method node, from which they were generated.
Test suites group test cases to simplify project navigation.
To display test data generation dialog: select method > click on properties window > scroll down > click button Generate test suite.
Data generation dialog will be displayed.
Dialog contains
In most cases all dialog parameters, can be left without change. To start generation click Ok button.
Three types of generators are available:
Test cases can be also added manually: click "Add test case button" in method properties > in dialog "New test case" choose values for all parameters > Click Ok.
Generated test cases can be exported to a custom text format.
Exporting test cases: select method > in properties window, in section "Test cases" select test cases to export > click "Export selected" button. "Export test suites" dialog will be displayed.
In "Template" combo-box one of four templates can be selected: CSV, XML, Gherkin, JSON. Default template text is displayed below template type. It can be edited to user's needs. Button "Update preview" generates "Sample preview" of data using the template from above. Click Ok do export test cases in defined format to local computer. Data file will be downloaded to default download folder.
User can export test cases during data generation. Click button "Export online" in method properties window.
Compared to standard data generation dialog it has additional section which allows to choose export template.
Current model can be saved to user's computer via export function.
Exporting current model: go to Main menu > choose option "File" > choose option "Export".
Model file in XML format will be downloaded to default download folder.
Previously exported model in XML format can be imported to current editor. Remark: the former model from editor will be removed.
Importing model: go to main menu > choose option "File" > browse for file > confirm import.