Getting Started

Aerial is designed to be extensible and to cover various input and output formats. It should be extensible not only by internal design it should also provide an ability to include some external modules which can be easily used together with the entire engine. Mainly, it’s all about being able to create some kind of plug-ins. There are several areas where it can be done:

• Input readers - components responsible for getting input data from some external source (any external system, file system etc.)

• Output writers - components responsible for producing the output in some specific format

• Scenario generators - components responsible for custom algorithms implementation which are targeted to produce new types of scenarios

• Test Data generators - components targeted to implement various settings and algorithms for custom data types and corresponding input values generation process

All of the above component types implement specific interface and main things the Aerial needs are:

• Configuration - the engine itself should be configured to use or include each specific module from specific location. Otherwise, it is decided that the component operates with built-in classes

• Library availability in classpath - since we use Java and create some modules which are stand-alone libraries they definitely should be included into classpath before engine starts using it

All the above things are needed to be defined. On this page we’ll describe each of the component types in more details with examples of how to extend existing functionality in the direction of each specific component.

Custom Input Readers

Since version 0.0.4

Overview

All Aerial input readers are defined via classes extending AerialReader abstract class. Actually this class only defines default constructor and prototypes for core methods. They are:

Since all the above methods are pretty typical by their structure and functions they are used in typical way. Actually, all necessary set of actions are performed by AerialProcessor class so it is highly recommended to keep existing structure and approaches for AerialReader extensions.

Write Custom Reader

All classes inherited from AerialReader class should have constructor like:

1
2
3

public  AerialReader(AerialParams params, AerialTagList tagsValue) {
...
}

Tags handling isn’t really required. It is still desired feature but the actual tags handling is up to each specific implementation. There is no any specific interface for it. Actually, all user needs to do for tags is to fill their values depending on some rule. If tags are empty they simply won’t be used in generated files.

Configure Aerial to Use Custom Reader

Custom reader class can be passed as readerClass named parameter, e.g. readerClass=com.sample.CustomReaderClass. At the same time the input type parameter should be defined as CUSTOM.

Custom Output Writers

Since version 0.0.4

Overview

All Aerial output writers are defined via classes extending AerialWriter abstract class. It is abstract class defining common methods which should be implemented by any writer class. They are:

Write Custom Writer

Configure Aerial to Use Custom Writer

Custom writer class can be passed as writerClass named parameter, e.g. writerClass=com.sample.CustomWriterClass. At the same time the output type parameter should be defined as CUSTOM.

Custom Types Definition

Since version 0.0.5

Overview

In some cases we have some data which is either very specific to application under test or it is some data which is logically grouped and you need to apply data generation for that using some specific rules. This is the case where built-in types are not enough and we need to use some custom type. For instance, we can create some custom type to operate with address which is the combination of strings and numbers in specific order.

Write Custom Input Type

Every custom type should be an extension of ValueExpression class. In this class we should override the following methods:

Here is an example of custom input type:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

package com.github.mkolisnyk.aerial.datagenerators;

import java.util.ArrayList;
import java.util.List;

import com.github.mkolisnyk.aerial.document.InputRecord;
import com.github.mkolisnyk.aerial.expressions.ValueExpression;

public class CustomExternalTypeExpression extends ValueExpression {

    @Override
    public String getMatchPattern() {
        return "(.*)";
    }

    @Override
    public String getValueTypeName() {
        return "Season";
    }

    public CustomExternalTypeExpression(InputRecord inputValue) {
        super(inputValue);
    }

    @Override
    public List<InputRecord> generate() throws Exception {
        List<InputRecord> result = new ArrayList<InputRecord>() {
            {
                new InputRecord(
                        getInput().getName(),
                        getInput().getType(),
                        "Winter",
                        getInput().getCondition(),
                        true);
                new InputRecord(
                        getInput().getName(),
                        getInput().getType(),
                        "Spring",
                        getInput().getCondition(),
                        true);
                new InputRecord(
                        getInput().getName(),
                        getInput().getType(),
                        "Summer",
                        getInput().getCondition(),
                        true);
                new InputRecord(
                        getInput().getName(),
                        getInput().getType(),
                        "Autumn",
                        getInput().getCondition(),
                        true);
                new InputRecord(
                        getInput().getName(),
                        getInput().getType(),
                        "Unknown",
                        getInput().getCondition(),
                        false);
            }
        };
        return result;
    }
}

In some cases we may need to define custom input type as an inner class. It can be done in the same fashion but with some restrictions: 1. That should be just a top level sub-class. So, inner class of inner class wouldn’t work 2. The container class should have default constructor

Configure Aerial to Use Custom Input Type

The list of classes representing custom types is defined either via aerial.types.custom.classes global property or via similar named system property. The value should contain canonical names as well as those classes should be available in the classpath.

Custom Scenario Generators

Since version 0.0.6

Overview

Besides standard generated scenarios Aerial provides an ability to extend case scenario generation engine to define specific scenarios which should be generated based on input.

Write Custom Scenario Generator

All custom scenarios must be an implementation of CaseScenarioGenerator class. Mainly we should implement the following methods:

Configure Aerial to Use Custom Scenario Generator

The list of custom classes can be configured via aerial.gen.custom.classes configuration property or the same system property.

News