path: root/doc/book-enea-edge-automation-user-guide/doc/automation_framework_test_harness.xml

<?xml version="1.0" encoding="UTF-8"?>
<chapter id="auto_fw_test_harness">
  <title>Enea Edge Automation</title>

  <section id="AFTH_structure">
    <title>File Structure</title>

    <para>Enea Edge Automation is an open-source product, with the following
    directory structure:</para>

    <itemizedlist spacing="compact">
      <listitem>
        <para>ansible.cfg</para>
      </listitem>

      <listitem>
        <para>automation_framework</para>
      </listitem>

      <listitem>
        <para>CHANGELOG</para>
      </listitem>

      <listitem>
        <para>environment_variables.sh</para>
      </listitem>

      <listitem>
        <para>modules</para>
      </listitem>

      <listitem>
        <para>setup_env_requirements.txt</para>
      </listitem>

      <listitem>
        <para>setup_env.sh</para>
      </listitem>

      <listitem>
        <para>test_harness</para>
      </listitem>

      <listitem>
        <para>unit_tests</para>
      </listitem>

      <listitem>
        <para>VERSION</para>
      </listitem>
    </itemizedlist>

    <para>Each file/directory is described in more details in the following
    sections.</para>

    <section id="create_virt_test_env">
      <title>Creating the Virtual Environment for Testing</title>

      <para>The <filename>setup_env.sh</filename>,
      <filename>setup_env_requirements.txt</filename> and
      <filename>environment_variables.sh</filename> files are used to create
      the testing virtual environment, using the following
      prerequisites:</para>

      <itemizedlist spacing="compact">
        <listitem>
          <para>The environment variable</para>
        </listitem>

        <listitem>
          <para>Python packages</para>
        </listitem>

        <listitem>
          <para>Ansible package(s)</para>
        </listitem>
      </itemizedlist>

      <para>The <filename>environment_variables.sh</filename> script sets the
      environment variables, the
      <filename>setup_env_requirements.txt</filename> file contains the
      mapping between the package name and its version, and the
      <filename>setup_env.sh</filename> script creates a testing virtual
      environment.</para>

      <para>The <filename>setup_env.sh</filename> does the following:</para>

      <itemizedlist spacing="compact">
        <listitem>
          <para>Checks if the <literal>Python 3</literal> and
          <literal>pip</literal> packages are installed on the host. If at
          least one package is not installed on the host, then an error is
          displayed and the script stops.</para>
        </listitem>

        <listitem>
          <para>Creates and activates the <literal>testHarness-venv</literal>
          virtual environment.</para>
        </listitem>

        <listitem>
          <para>Upgrades the <literal>pip</literal> package to the newest
          version.</para>
        </listitem>

        <listitem>
          <para>Installs the packages defined in
          <filename>setup_env_requirements.txt</filename> on the virtual
          environment.</para>
        </listitem>

        <listitem>
          <para>Sets the environment variables defined in
          <filename>environment_variables.sh</filename> on the virtual
          environment.</para>
        </listitem>
      </itemizedlist>
    </section>

    <section id="version_changelog">
      <title>VERSION and CHANGELOG</title>

      <para>The <filename>VERSION</filename> and
      <filename>CHANGELOG</filename> files contain information about the
      version, build number, and all the notable changes added in the Enea
      Edge Automation.</para>
    </section>

    <section id="module_enea_dir">
      <title>The modules/enea directory</title>

      <para>The <literal>modules/enea</literal> directory contains the
      following:</para>

      <itemizedlist spacing="compact">
        <listitem>
          <para><literal>config</literal> - contains the configuration files
          that need to be updated in order to successfully run the Enea Edge
          Automation. For more details, see <xref
          linkend="AFTH_cofig" />.</para>
        </listitem>

        <listitem>
          <para><literal>scenario</literal> - contains the test scenarios. The
          test scenarios include custom script examples, service chaining VNF
          examples and so on.</para>
        </listitem>

        <listitem>
          <para><literal>VNF_images</literal> - contains the VNF images that
          are used in test scenarios.</para>
        </listitem>
      </itemizedlist>
    </section>

    <section id="automation_framework_dir">
      <title>The automation_framework directory</title>

      <para>The <literal>automation_framework</literal> directory includes all
      the Python scripts used by the Automation Framework. Each Python script
      implements a class that defines a functionality of the Enea Edge
      Management application.</para>

      <para>The Python scripts can be split into the following:</para>

      <itemizedlist>
        <listitem>
          <para>The <filename>ManagementHTTPClientRestAPIv2.py</filename>
          script, where the <literal>ManagementClient</literal> class is
          defined. This class communicates with the Enea Edge Management
          application via REST API.</para>

          <note>
            <para>The <filename>uCPEMgrHTTPClientRestAPIv2.py</filename>
            script is where the <literal>uCPEMgrHTTPClient</literal> class is
            defined. The <literal>uCPEMgrHTTPClient</literal> class is a
            wrapper of the <literal>ManagementClient</literal> class. This
            script is deprecated and will be removed starting with the next
            major release.</para>
          </note>
        </listitem>

        <listitem>
          <para>Other Python scripts, where the classes for the Enea Edge
          Management module are defined. Each class inherits the
          <literal>ManagementClient</literal> class and uses its methods to
          communicate with the Enea Edge Management application via the REST
          API. Each class corresponds to an Enea Edge Management
          module.</para>

          <para><emphasis role="bold">Example</emphasis>: the
          <filename>OfflineConfigHandler.py</filename> script, where the
          <literal>OfflineConfigHandler</literal> class is defined. Inside
          this class, the methods for offline configuration functionality are
          implemented: <literal>addOfflineConfigStore</literal>,
          <literal>deleteOfflineConfigStore</literal>,
          <literal>uploadConfigToDevice</literal> and so on.</para>
        </listitem>
      </itemizedlist>
    </section>

    <section id="unit_test_dir">
      <title>The unit_test directory</title>

      <para>The <literal>unit_test</literal> directory contains:</para>

      <itemizedlist spacing="compact">
        <listitem>
          <para>JSON files for complex scenarios with multiple
          operations.</para>
        </listitem>

        <listitem>
          <para>The Python <literal>unit-test</literal> class.</para>
        </listitem>

        <listitem>
          <para>Loader scripts for generating specific test cases for the
          available Python script.</para>
        </listitem>
      </itemizedlist>

      <para>The generated test cases are injected into the Python
      <literal>unit-test</literal> suite class to run using the Python
      <literal>unit-test</literal> framework.</para>
    </section>

    <section id="test_harn_ansible">
      <title>The test_harness directory and ansible.cfg</title>

      <para>The <filename>ansible.cfg</filename> file represents the
      configuration file for Test Harness. The Ansible configurations have
      default values delivered in the archive, but they can be changed.
      <emphasis role="bold">Example</emphasis>: for a more extended output,
      change the output from selective to debug.</para>

      <para>The <literal>test_harness</literal> directory contains all the
      implemented playbooks. This directory is structured in multiple
      subdirectories, each subdirectory represents a functionality of the Enea
      Edge Management application. Each implemented playbook from this
      directory runs a method from a Python class from the
      <literal>automation_framework</literal> directory. Each playbook is an
      atomic operation, a basic operation that need to be tested. These
      playbooks are used in complex test scenarios.</para>
    </section>

    <section id="log_dir">
      <title>The log directory</title>

      <para>The <literal>log</literal> directory is added in the directory
      structure by the <filename>setup_env.sh</filename> script. The
      <filename>setup_env.sh</filename> script stores the output logs in the
      <filename>setup_env.log</filename> file. The Ansible playbooks store the
      logs in the <filename>ansible.log</filename> file. The Python scripts
      store the logs in the <filename>debug.log</filename> file.</para>
    </section>
  </section>

  <section id="AFTH_cofig">
    <title>Configuring the System</title>

    <para>The configuration files must be updated before using Enea Edge
    Automation. They are stored in the <literal>modules/enea/config</literal>
    directory.</para>

    <para>The configuration files are split according to the component that is
    used in the testing process:</para>

    <itemizedlist spacing="compact">
      <listitem>
        <para>The Enea Edge Management application</para>
      </listitem>

      <listitem>
        <para>uCPE Devices</para>
      </listitem>

      <listitem>
        <para>VNFs</para>
      </listitem>
    </itemizedlist>

    <section id="config_files_mg">
      <title>Configuration Files for the Enea Edge Management
      application</title>

      <para>In order to create a connection with the Enea Edge Management
      application, the following parameters have to be specified:</para>

      <itemizedlist spacing="compact">
        <listitem>
          <para>Enea Edge Management username</para>
        </listitem>

        <listitem>
          <para>Enea Edge Management password</para>
        </listitem>

        <listitem>
          <para>Enea Edge Management IP address or FQDN</para>
        </listitem>
      </itemizedlist>

      <para><emphasis role="bold">Updating the configuration
      file</emphasis></para>

      <orderedlist>
        <listitem>
          <para>Open
          <filename>modules/enea/config/Management/management01.json</filename></para>

          <programlisting>{
  "ucpe_usr":"admin",
  "ucpe_pass":"admin",
  "ucpe_host":"172.24.3.92"
}</programlisting>
        </listitem>

        <listitem>
          <para>Update the username, password and IP address or FQDN.</para>

          <note>
            <para>The
            <filename>modules/enea/config/uCPEManager/ucpem01.json</filename>
            file is a symbolic link to the
            <filename>modules/enea/config/Management/management01.json</filename>
            file. It is deprecated, and it will be removed starting with the
            next major release.</para>
          </note>
        </listitem>
      </orderedlist>

      <para>It is possible to use another JSON file for the connection with
      the Enea Edge Management application.</para>

      <para><emphasis role="bold">Changing the path for the Enea Edge
      Management JSON file</emphasis></para>

      <orderedlist>
        <listitem>
          <para>Open the
          <filename>automation_framework/ManagementHTTPClientRestAPIv2.py</filename>
          file.</para>
        </listitem>

        <listitem>
          <para>Go to the <literal>create_json_file</literal> method from the
          <literal>ManagementConfig</literal> class.</para>
        </listitem>

        <listitem>
          <para>Change the path of the Enea Edge Management JSON file in the
          <literal>self.ucpe_json_file</literal> variable.</para>
        </listitem>
      </orderedlist>
    </section>

    <section id="config_files_ucpe_devices">
      <title>Configuration Files for uCPE Devices</title>

      <para>The <literal>modules/enea/config/uCPEDevices</literal> directory
      contains the following:</para>

      <itemizedlist spacing="compact">
        <listitem>
          <para>Examples of the configuration files for different uCPE
          Devices:
          <literal>inteld1521-16</literal>,<literal>inteld1521-17</literal>,
          and so on.</para>
        </listitem>

        <listitem>
          <para>The scripts for generating all configuration files in
          <literal>scripts</literal> folder.</para>
        </listitem>
      </itemizedlist>

      <para>The following scripts are implemented to generate the
      configuration files:</para>

      <itemizedlist spacing="compact">
        <listitem>
          <para><filename>generate_device_config.py</filename> - generates the
          JSON configuration file for the uCPE Device.</para>
        </listitem>

        <listitem>
          <para><filename>generate_bridges_config_files.py</filename> -
          generates configuration files for all possible OVS bridges created
          on the uCPE Device.</para>
        </listitem>

        <listitem>
          <para><filename>generate_nics_config_files.py</filename> - generates
          the configuration files for all possible NICs created on the uCPE
          Device.</para>
        </listitem>
      </itemizedlist>

      <section id="generate_config">
        <title>Generating Device config</title>

        <para>Before running the script, check the following:</para>

        <itemizedlist spacing="compact">
          <listitem>
            <para>The available NICs on the target.</para>
          </listitem>

          <listitem>
            <para>The device ID.</para>
          </listitem>

          <listitem>
            <para>The IP address of the uCPE Device.</para>
          </listitem>
        </itemizedlist>

        <para><emphasis role="bold">Generating the device
        config</emphasis></para>

        <note>
          <para>Make sure the management interface, the one that ensures the
          connection between the uCPE Device and the Enea Edge Management
          application, is not used when generating the JSON configuration
          files.</para>
        </note>

        <orderedlist>
          <listitem>
            <para>Run <filename>generate_device_config.py</filename>:</para>

            <programlisting>python generate_device_config.py
Device name: test
Device ID: test_id
Device groupings tags [ ]: test_id
uCPE Device version [2.5.0]: 2.5.0
Device IP address [No]: 10.0.0.1
Call home [false]:
Mgmt network interface - it must not be the management interface [No]: eth0
WAN network interface - it must not be the management interface [No]: eth1
LAN network interface - it must not be the management interface [No]: eth2
WAP network interface - it must not be the management interface [No]: wlan0

The following JSON config file was successfully created (uCPE Device config file):
test.json

The following JSON config file was successfully created (config store file):
store.json</programlisting>
          </listitem>

          <listitem>
            <para>Check the configuration files in the
            <literal>modules/enea/config/uCPEDevices/test</literal>
            directory:</para>

            <itemizedlist>
              <listitem>
                <para><filename>test.json</filename> file - contains all the
                input parameters for the <literal>test</literal>
                device:</para>

                <programlisting>{
    "deviceId": "test_id",
    "deviceGroupingTags": "test_id",
    "name": "test",
    "version": "2.5.0",
    "callHome": "false",
    "address": "10.0.0.1",
    "certificate": null,
    "description": "test",
    "maintMode": "false",
    "passphrase": null,
    "password": "",
    "port": "830",
    "username": "root",
    "interfaces": {
        "mgmt": "eth0",
        "wan": "eth1",
        "lan": "eth2",
        "wap": "wlan0"
    }
}</programlisting>
              </listitem>

              <listitem>
                <para><filename>store.json</filename> file - contains the
                input parameters used for creating an offline config for the
                uCPE Device:</para>

                <programlisting>{
    "version": "2.5.0",
    "deviceId": "test_id",
    "deviceGroupingTags": "test_id",
    "description": "Config file for test"
}</programlisting>
              </listitem>
            </itemizedlist>
          </listitem>
        </orderedlist>

        <para>The <filename>generate_device_config.py</filename> script can be
        executed in a non-interactive way using the
        <command>--non-interactive</command> option, as follows:</para>

        <programlisting>python generate_device_config.py --non-interactive --device_name=test
  --device_id=test_id --device_grouping_tags=test_id --version 2.5.0
  --device_ip_addr=10.0.0.1 --call_home=false --mgmt_nic=eth0 --wan_nic=eth1
  --lan_nic=eth2 --wap_nic=wlan0</programlisting>

        <para>The names of the interfaces (<literal>mgmt_*, wan_*,
        lan_*</literal> and <literal>wap_*</literal>) are used to generate the
        config file for NIC and OVS bridges. Their values depend on the input
        scenario.</para>

        <para>When the script is interactively run, the parameter's value
        between the square brackets is the default one. It can be omitted when
        the script is non-interactively run.</para>
      </section>

      <section id="nic_config_files">
        <title>Generating NIC config files</title>

        <para><emphasis role="bold">Generating NIC config
        files</emphasis></para>

        <orderedlist>
          <listitem>
            <para>Run
            <filename>generate_nics_config_files.py</filename>:</para>

            <programlisting>python generate_nics_config_files.py
Device name: test
Check 'test' directory for JSON configuration files</programlisting>
          </listitem>

          <listitem>
            <para>Check the configuration files for all interface types in the
            <literal>modules/enea/config/uCPEDevices/test</literal> directory.
            The interface name is defined in the
            <filename>test.json</filename> file. The NIC config files have the
            following structure:
            <literal>&lt;interface_name&gt;_&lt;interface_type&gt;_nic.json</literal>.
            For the <literal>eth2</literal> lan interface, the following JSON
            files are created:</para>

            <itemizedlist>
              <listitem>
                <para><filename>lan_dpdk_nic.json</filename> - contains:
                Interface type: <literal>DPDK</literal>; Sub-type:
                <literal>vfio-pci</literal>.</para>

                <programlisting> {
    "name": "eth2",
    "dpdk_type": "vfio-pci"
}</programlisting>
              </listitem>

              <listitem>
                <para><filename>lan_sriov_nic.json</filename> - contains
                Interface type: <literal>SR-IOV, SR-IOV</literal>; Mode:
                <literal>adapter-pool</literal>; Num VFS:
                <literal>2</literal>.</para>

                <programlisting>{
    "name": "eth2",
    "sriov_mode": "adapter-pool",
    "sriov_num_vfs": "2"
}</programlisting>
              </listitem>

              <listitem>
                <para><filename>lan_wan_nic.json</filename> - contains
                Interface type: <literal>WAN</literal>; Address assignment:
                <literal>DHCP</literal>.</para>

                <programlisting>{
    "name": "eth2",
    "address_assignment": "dhcp",
    "ip_address": "null",
    "gateway": "null",
    "netmask": "null"
}</programlisting>
              </listitem>

              <listitem>
                <para><filename>wap_wap_nic.json</filename> - contains
                Interface type: <literal>WAP</literal>; Country Code:
                <literal>SE</literal>; Wireless band:
                <literal>band5GHz</literal>; Wireless Mode: <literal>802.11
                g/n</literal>; Radio Channel: <literal>42 (80 MHz
                wide)</literal>.</para>

                <programlisting>{
    "name": "wlan0",
    "country_code": "SE",
    "wireless_band": "band5GHz",
    "wireless_mode": "802.11 ac/n",
    "radio_channel": "42 (80 MHz wide)"
}</programlisting>
              </listitem>
            </itemizedlist>
          </listitem>
        </orderedlist>

        <para>The <filename>generate_nics_config_files.py</filename> script
        can be executed in a non-interactive way, as follows:</para>

        <programlisting>python generate_nics_config_files.py  --device_name=test
Check 'test' directory for JSON configuration files</programlisting>

        <para>The values from the JSON files depend on the input
        scenario.</para>
      </section>

      <section id="generate_ovs_config">
        <title>Generating OVS config files</title>

        <para><emphasis role="bold">Generating OVS config
        files</emphasis></para>

        <orderedlist>
          <listitem>
            <para>Run
            <filename>generate_bridges_config_files.py</filename>:</para>

            <programlisting>python generate_bridges_config_files.py
Device name: test
Check 'test' directory for JSON configuration files</programlisting>
          </listitem>

          <listitem>
            <para>Check the configuration files in the
            <literal>modules/enea/config/uCPEDevices/test</literal> directory.
            The name of OVS bridges type has the following structure:
            <literal>&lt;bridge_type&gt;_br.json</literal>. The following JSON
            files are created:</para>

            <itemizedlist>
              <listitem>
                <para><filename>ibm_br.json</filename> - contains information
                about the <literal>In-band management OVS
                bridge</literal>:</para>

                <programlisting>{
    "name": "ibm_br",
    "type": "inband_mgmt"
}</programlisting>
              </listitem>

              <listitem>
                <para><filename>sfc_br.json</filename> - contains:
                <literal>Dataplane OVS bridge</literal>; Type:
                <literal>integration</literal>:</para>

                <programlisting>{
    "name": "sfc_br",
    "type": "dataplane",
    "subType": "integration",
    "interfaces": []
}</programlisting>
              </listitem>

              <listitem>
                <para><filename>vnfmgmt_ipv4_br.json</filename> - contains
                <literal>VNF Management OVS bridge, IPv4</literal>:</para>

                <programlisting>{
    "name": "vnfmgmt_ipv4_br",
    "type": "vnfMgmt",
    "vnfMgmtAddress": "10.0.0.1"
}</programlisting>
              </listitem>

              <listitem>
                <para><filename>vnfmgmt_ipv6_br.json</filename> - contains
                <literal>VNF Management OVS bridge, IPv6</literal>:</para>

                <programlisting>
{
    "name": "vnfmgmt_ipv6_br",
    "type": "vnfMgmt",
    "vnfMgmtAddress": "2001:db8:0:0:0:0:0:0"
}</programlisting>
              </listitem>

              <listitem>
                <para><filename>lan_br.json</filename> - contains
                <literal>Dataplane OVS bridge</literal>; Type:
                <literal>communication</literal>; Interface:
                <literal>eth2</literal>:</para>

                <programlisting>lan_br.json
{
    "name": "lan_br",
    "type": "dataplane",
    "subType": "communication",
    "interfaces": [
        "eth2"
    ]
}</programlisting>
              </listitem>

              <listitem>
                <para><filename>wap_br.json</filename> - contains
                <literal>Dataplane OVS bridge</literal>; Type:
                <literal>communication</literal>:</para>

                <programlisting>{
    "name": "wap_br",
    "type": "dataplane",
    "subType": "communication",
    "interfaces": []
}</programlisting>
              </listitem>
            </itemizedlist>
          </listitem>
        </orderedlist>

        <para>The <filename>generate_bridges_config_files.py</filename> script
        can be executed in a non-interactive way, as follows:</para>

        <programlisting>python generate_bridges_config_files.py --device_name=test
Check 'test' directory for JSON configuration files</programlisting>

        <para>The values from the JSON files depend on the input
        scenario.</para>
      </section>
    </section>

    <section id="config_file_vnf">
      <title>Configuration Files for the VNF</title>

      <para>The VNF directory <literal>modules/enea/config/VNF</literal>,
      contains subdirectories for each defined VNF:
      <literal>fortigateFWImage</literal>, <literal>junipervSRXImae</literal>
      and so on.</para>

      <para>Each VNF subdirectory contains configuration files for:
      cloud-init, VNF Descriptors, VNF instances. These configuration files
      are examples used in test scenarios from Enea Edge Automation.</para>

      <para>For more details about the test scenarios from
      <literal>modules/enea/scenario/</literal>, see <xref
      linkend="AFTH_test" />.</para>
    </section>
  </section>

  <section id="AFTH_automation">
    <title>The Automation Framework</title>

    <para>The Automation Framework scripts described in the following section
    are located in the
    <literal>&lt;Automation-installerdir&gt;/automation_framework</literal>
    directory.</para>

    <section id="httpclient_class">
      <title>The ManagementClient class</title>

      <para>The <literal>ManagementClient</literal> class is implemented in
      the <filename>ManagementHTTPClientRestAPIv2.py</filename> script.</para>

      <para>The scope of this class is to send REST API requests to the Enea
      Edge Management application. The methods of the
      <literal>ManagementClient</literal> class represent REST API calls to
      the Enea Edge Management application or ways for creating the objects
      that are used as input for sending the request.</para>

      <para>The dictionaries used as the payload in the REST API requests are
      created in methods from this class. The output of these methods is used
      as input for the REST API request payload.</para>

      <para>Each method has a short description in the header, as
      follows:</para>

      <itemizedlist spacing="compact">
        <listitem>
          <para>The scope of the method</para>
        </listitem>

        <listitem>
          <para>The input parameters</para>
        </listitem>

        <listitem>
          <para>The return value from the source code</para>
        </listitem>

        <listitem>
          <para>The URL for the REST API call</para>
        </listitem>

        <listitem>
          <para>The payload dictionary for the REST API call</para>
        </listitem>
      </itemizedlist>

      <para>Other classes from the <literal>automation_framework</literal>
      directory inherit this class, and call its methods.</para>

      <note>
        <para>The <literal>uCPEMgrHTTPClientRestAPIv2</literal> class is a
        wrapper of the <literal>ManagementClient</literal> class. All the
        methods defined in the <literal>ManagementClient</literal> class can
        be used when the <literal>uCPEMgrHTTPClientRestAPIv2</literal> object
        is instantiated. The <literal>uCPEMgrHTTPClientRestAPIv2</literal>
        object is deprecated and will be removed starting with the next major
        release. It is recommended to use the
        <literal>ManagementClient</literal> class instead.</para>
      </note>

      <para><emphasis role="bold">Examples</emphasis>:</para>

      <orderedlist spacing="compact">
        <listitem>
          <para>uCPE Device functionalities are defined in the
          <literal>uCPEDeviceHandler</literal> class.</para>
        </listitem>

        <listitem>
          <para>The <literal>uCPEDeviceHandler</literal> class inherits the
          <literal>ManagementClient</literal> class.</para>
        </listitem>

        <listitem>
          <para>The <literal>uCPEDeviceHandler</literal> method calls methods
          from <literal>ManagementClient</literal> to send requests to the
          Enea Edge Management application.</para>
        </listitem>

        <listitem>
          <para>Methods from <literal>ManagementClient</literal> create the
          payload dictionary starting from the input parameters and send the
          REST API request.</para>
        </listitem>

        <listitem>
          <para>The output of the methods are parsed and analyzed by methods
          from the <literal>uCPEDeviceHandler</literal> class.</para>
        </listitem>
      </orderedlist>
    </section>

    <section id="mg_functionalities">
      <title>Handlers for Enea Edge Management Functionalities</title>

      <para>In Enea Edge Automation the modules of the Enea Edge Management
      application are represented by Python classes called
      <literal>Handlers</literal>. Each Python class represents a
      functionality of the Enea Edge Management application.</para>

      <para>These classes are implemented in the Python scripts that have a
      <literal>Handler</literal> string included in the name. The name of the
      classes is the same as the name of Python script.</para>

      <para>For the usage of any class, run the Python script with the
      <emphasis role="bold">--help</emphasis> option:</para>

      <programlisting>python automation_framework/uCPEDeviceHandler.py --help
Usage: uCPEDeviceHandler.py [OPTIONS] [PARAMETERS]...

Options:
  -v, --verbose           Get info about the methods and parameters
  -d, --device_name TEXT  The uCPE Device name
  -m, --method TEXT       The atomic operation you want to run
  -f, --config_file TEXT  The config file for NIC or bridges (optional
                          argument)

  -o, --display_output    Display output of the method
  --help                  Show this message and exit.</programlisting>

      <para>For displaying all the available Python APIs and their parameters,
      run the Python script with the <literal>-v/--verbose</literal> option. A
      few examples will be displayed in the following sections.</para>

      <para>If the parameters of the Python APIs contain <literal>=</literal>
      in their description that means they have a default value that is
      already defined in the Python script. The default value of the parameter
      is displayed after this symbol.</para>

      <para>To use or change the default value of one or more parameters,
      perform one of the following methods:</para>

      <itemizedlist>
        <listitem>
          <para>Run the Python API using only the values of the parameters
          without specifying the parameters' names. All parameters will be
          given and the value will be the position of each parameter.</para>
        </listitem>

        <listitem>
          <para>Run the Python API using the
          <literal>&lt;parameter_name&gt;=</literal> syntax. Only specific
          parameters will be given and they will be specified as
          <literal>&lt;parameter_name&gt;=&lt;parameter_value&gt;</literal>.</para>
        </listitem>

        <listitem>
          <para>Run the Python API with a mix of parameters. Mandatory
          parameters will be given without specifying their name (their
          position will be used in this situation) and the optional parameters
          will be given, using the syntax:<literal>
          &lt;parameter_name&gt;=&lt;parameter_value&gt;</literal>.</para>
        </listitem>
      </itemizedlist>

      <para>In the <literal>test_harness/&lt;module name&gt;</literal>
      directory, the Ansible Playbooks are implemented for running the Python
      scripts from Enea Edge Automation. The name of the Ansible Playbooks is
      the same as the name of the Python method. The Python command is between
      the <literal>&lt;command&gt; ... &lt;/command&gt;</literal> tags from
      the <literal>*.yml</literal> files.</para>

      <section id="mg_functionalities_ucpe">
        <title>uCPE Device</title>

        <para>The Enea Edge Management functionalities for the uCPE Device are
        implemented, as follows:</para>

        <itemizedlist spacing="compact">
          <listitem>
            <para><filename>automation_framework/uCPEDeviceHandler.py</filename>
            - <literal>uCPEDeviceHandler</literal> class with methods for
            adding a device, removing a device, waiting a device to be up,
            getting the uCPE Device status, and so on.</para>
          </listitem>

          <listitem>
            <para><filename>automation_framework/Configuration.py</filename> -
            <literal>Configuration</literal> class with methods for
            configuring the uCPE Device: DPDK, external interface, and OVS
            bridges. The methods of the <literal>Configuration</literal> class
            are used in the <literal>uCPEDeviceHandler</literal> and
            <literal>OfflineConfigHandler</literal> classes.</para>
          </listitem>
        </itemizedlist>

        <para>The <literal>uCPEDeviceHandler</literal> class inherits the
        <literal>Configuration</literal> class and all its methods.</para>

        <para>The functionalities for <literal>configure external
        interfaces</literal>, <literal>configure OVS bridges</literal> can be
        run using the:</para>

        <itemizedlist spacing="compact">
          <listitem>
            <para>Configuration file located in
            <literal>modules/enea/config/uCPEDevices</literal>, with the
            <emphasis role="bold">-f</emphasis> option.</para>
          </listitem>

          <listitem>
            <para>Input parameters.</para>
          </listitem>
        </itemizedlist>

        <para>The <literal>addDevice</literal> and
        <literal>removeDevice</literal> functionalities use the
        <filename>modules/enea/config/uCPEDevice/&lt;device_name&gt;/&lt;device_name&gt;.json</filename>
        config file, as the default.</para>

        <para>The other functionalities can be run using only input
        parameters.</para>

        <para>To list the implemented methods (functionalities), run the
        script with the <emphasis role="bold">-v/--verbose</emphasis>
        option:</para>

        <programlisting>python automation_framework/uCPEDeviceHandler.py -v
Info about uCPEDeviceHandler methods
...
Method: addDpdkExternalInterface
Parameters: name, dpdkType
...</programlisting>

        <para>The syntax for running
        <literal>addDpdkExternalInterface</literal>, using the configuration
        file:</para>

        <programlisting>python automation_framework/uCPEDeviceHandler.py -d &lt;device_name&gt; -m 
addDpdkExternalInterface -f 
modules/enea/config/uCPEDevices/&lt;device_name&gt;/&lt;interface_name&gt;_dpdk_nic.json </programlisting>

        <para><emphasis role="bold">Example:</emphasis></para>

        <programlisting>python automation_framework/uCPEDeviceHandler.py -d vep1445-8 -m 
addDpdkExternalInterface -f modules/enea/config/uCPEDevices/vep1445-8/lan_dpdk_nic.json</programlisting>

        <para>The syntax for running the
        <literal>addDpdkExternalInterface</literal> functionality:</para>

        <programlisting>python automation_framework/uCPEDeviceHandler.py -d &lt;device_name&gt; -m 
addDpdkExternalInterface &lt;interface_name&gt; &lt;dpdk_type&gt;</programlisting>

        <para><emphasis role="bold">Example:</emphasis></para>

        <programlisting>python automation_framework/uCPEDeviceHandler.py -d vep1445-8 -m 
addDpdkExternalInterface eno4 vfio-pci</programlisting>
      </section>

      <section id="offline_config_mg_func">
        <title>Offline config</title>

        <para>The Enea Edge Management functionalities regarding the offline
        configuration are implemented as follows:</para>

        <itemizedlist>
          <listitem>
            <para><filename>automation_framework/OfflineConfigHandler.py</filename>
            - <literal>OfflineConfigHandler</literal> class has methods for
            adding an offline config, removing an offline config, uploading an
            offline config on a uCPE Device, and so on.</para>
          </listitem>

          <listitem>
            <para><filename>automation_framework/Configuration.py</filename> -
            <literal>Configuration</literal> class has methods for configuring
            the uCPE Device: DPDK, external interface, and OVS bridges. The
            methods of the <literal>Configuration</literal> class are used in
            the <literal>uCPEDeviceHandler</literal> and
            <literal>OfflineConfigHandler</literal> classes.</para>
          </listitem>
        </itemizedlist>

        <para>The <literal>OfflineConfigHandler</literal> class inherits the
        <literal>Configuration</literal> class with all its methods.</para>

        <para>The functionalities for the <literal>adding offline config
        store</literal>, <literal>removing offline config store</literal>,
        <literal>configuring external interfaces</literal>,
        <literal>configuring OVS bridges</literal> can be run using
        the:</para>

        <itemizedlist spacing="compact">
          <listitem>
            <para>Configuration file located in
            <literal>modules/enea/config/uCPEDevices</literal>.</para>
          </listitem>

          <listitem>
            <para>Input parameters.</para>
          </listitem>
        </itemizedlist>

        <para>The other functionalities can be run using only input
        parameters.</para>

        <para>To list the implemented methods (functionalities), run the
        script with the <emphasis role="bold">-v/--verbose</emphasis>
        option:</para>

        <programlisting>python automation_framework/OfflineConfigHandler.py -v
Info about OfflineConfigHandler methods
...
Method: addOfflineConfigStore
Parameters: version, deviceId, deviceGroupingTags, descr=''
...</programlisting>

        <para>The syntax for running the
        <literal>addOfflineConfigStore</literal> using the configuration
        file:</para>

        <programlisting>python automation_framework/OfflineConfigHandler.py -s &lt;store_name&gt; -m 
addOfflineConfigStore -f &lt;path_to_store_configuration_file&gt;</programlisting>

        <para><emphasis role="bold">Example:</emphasis></para>

        <programlisting>python automation_framework/OfflineConfigHandler.py -s testOfflineConfig -m 
addOfflineConfigStore -f modules/enea/config/uCPEDevices/test/store.json</programlisting>

        <para>The syntax for running the
        <literal>addOfflineConfigStore</literal> functionality using input
        parameters: <literal>version</literal>, <literal>deviceId</literal>,
        <literal>deviceGroupingTags</literal>, <literal>desc</literal>:</para>

        <programlisting>python automation_framework/OfflineConfigHandler.py -s &lt;store_name&gt; -m 
addOfflineConfigStore &lt;version&gt; &lt;deviceId&gt; &lt;deviceGroupingTags&gt;</programlisting>

        <para><emphasis role="bold">Example:</emphasis></para>

        <programlisting>python automation_framework/OfflineConfigHandler.py -s testStoreName -m  
addOfflineConfigStore 2.5.0 deviceId customerTag</programlisting>
      </section>

      <section id="custom_scripts_mg_func">
        <title>Custom scripts</title>

        <para>All the Enea Edge Management functionalities regarding the
        custom scripts are implemented in the
        <filename>CustomScriptsHandler.py</filename> script.</para>

        <para>The <literal>CustomScriptsHandler</literal> class is implemented
        in <filename>CustomScriptsHandler.py</filename> script.</para>

        <para>Examples of custom scripts are in the
        <literal>modules/enea/config/customScripts/</literal> directory. They
        can be used when running a Python method from the
        <literal>CustomScriptsHandler</literal> class.</para>

        <para>To list the implemented methods (functionalities), run the
        script with the <emphasis role="bold">-v/--verbose</emphasis>
        option:</para>

        <programlisting>python automation_framework/CustomScriptsHandler.py -v
Info about CustomScriptHandler methods
...
Method: uploadCustomScript
Parameters: customScript, phase
...</programlisting>

        <para>The syntax for running the <literal>uploadCustomScript</literal>
        functionality starting from the input parameters:</para>

        <programlisting>python automation_framework/CustomScriptsHandler.py -m 
uploadCustomScript &lt;customScript&gt; &lt;phase&gt;</programlisting>

        <para><emphasis role="bold">Example</emphasis>:</para>

        <programlisting>python automation_framework/CustomScriptsHandler.py -m uploadCustomScript 
modules/enea/config/customScripts/test_fail_after_once once-after-startup</programlisting>

        <para>All the other methods run in a similar way.</para>
      </section>

      <section id="device_upgrade_mg_func">
        <title>Device upgrade</title>

        <para>The Enea Edge Management functionalities regarding the uCPE
        Device upgrade are implemented in the
        <filename>DeviceUpgradeHandler.py</filename> script.</para>

        <para>The <literal>DeviceUpgradeHandler</literal> class is implemented
        in the <filename>DeviceUpgradeHandler.py</filename> script.</para>

        <para>To list the implemented methods (functionalities), run the
        script with the <emphasis role="bold">-v/--verbose</emphasis>
        option:</para>

        <programlisting>python automation_framework/DeviceUpgradeHandler.py -v
Info about DeviceUpgradeHandler methods
...
Method: uploadImage
Parameters: imagePath, type, module='VcpeAgent'
...</programlisting>

        <para>The syntax for running the <literal>uploadImage</literal>
        functionality starting from the input parameters:</para>

        <programlisting>python automation_framework/DeviceUpgradeHandler.py -m 
uploadImage &lt;imagePath&gt; &lt;type&gt;</programlisting>

        <para>The default value for the <literal>module</literal> is
        <literal>VcepAgent</literal>, cannot be changed and it is
        omitted.</para>

        <para><emphasis role="bold">Example:</emphasis></para>

        <programlisting>python automation_framework/DeviceUpgradeHandler.py -m uploadImage 
/tmp/enea-edge-runtime-xeon-d.tar.gz xeon-d</programlisting>

        <para>All the other methods run in a similar way.</para>
      </section>

      <section id="vnf_mg_func">
        <title>VNF</title>

        <para>The Enea Edge Management functionalities regarding the VNF are
        implemented in the <filename>VNFHandler.py</filename> script.</para>

        <para>The <literal>VNFHandler</literal> class is implemented in the
        <filename>VNFHandler.py</filename> script.</para>

        <para>To list the implemented methods (functionalities), run the
        script with the <emphasis role="bold">-v/--verbose</emphasis>
        option:</para>

        <programlisting>python automation_framework/VNFHandler.py -v
Info about VNFHandler methods
...
Method: getVNFDescriptorByName
Parameters: vnfDescriptorName
...</programlisting>

        <para>The syntax for running the
        <literal>getVNFDescriptorByName</literal> functionality starting from
        the input parameters:</para>

        <programlisting>python automation_framework/VNFHandler.py -m getVNFDescriptorByName &lt;vnfDescriptorName&gt; -o</programlisting>

        <para><emphasis role="bold">Example:</emphasis></para>

        <programlisting>python automation_framework/VNFHandler.py -m getVNFDescriptorByName fortigateImage -o</programlisting>

        <para>All the other methods run in a similar way.</para>
      </section>

      <section id="mg_funcs">
        <title>Enea Edge Management</title>

        <para>The functionalities regarding the Enea Edge Management
        configuration are implemented in the
        <filename>ManagementHandler.py</filename> script.</para>

        <para>The <literal>ManagementHandler</literal> class is implemented in
        the <filename>ManagementHandler.py</filename> script.</para>

        <para>To list the implemented methods (functionalities), run the
        script with the <emphasis role="bold">-v/--verbose</emphasis>
        option:</para>

        <programlisting>python automation_framework/ManagementHandler.py -v
Info about ManagementHandler methods
...
Method: getManagementVersion
Parameters(not needed): --
...</programlisting>

        <para>The syntax for running the
        <literal>getManagementVersion</literal> functionality is:</para>

        <programlisting>python automation_framework/ManagementHandler.py -m getManagementVersion -o</programlisting>

        <para>All the other methods run in a similar way.</para>

        <note>
          <para>The functionalities relating to the Enea Edge Management
          application configuration are also implemented in the
          <filename>uCPEManagerHandler.py</filename> script where the
          <literal>uCPEManagerHandler</literal> class is defined. The
          <literal>uCPEManagerHandler</literal> class is a wrapper of the
          <literal>ManagementHandler</literal> class. The
          <filename>uCPEManagerHandler.py</filename> file is deprecated and
          will be removed starting with the next major release. It is
          recommended to use the <filename>ManagementHandler.py</filename>
          script instead.</para>
        </note>
      </section>
    </section>

    <section id="auxiliar_classes">
      <title>Auxiliar classes</title>

      <section id="config_class">
        <title>The Configuration class</title>

        <para>The <literal>Configuration</literal> class is implemented in the
        <filename>Configuration.py</filename> script. The
        <literal>Configuration</literal> class cannot be independently
        used.</para>

        <para>The <literal>uCPEDeviceHandler</literal> and
        <literal>OfflineConfigHandler</literal> classes inherit the
        <literal>Configuration</literal> class. The methods should be
        implemented for both functionalities: uCPE Device and Offline
        config.</para>
      </section>

      <section id="logger_class">
        <title>The Logger Class</title>

        <para>The <literal>Logger</literal> class is implemented in the
        <filename>Logger.py</filename> script. It is inherited in all the
        classes defined in <literal>automation_framework</literal>.</para>

        <para>This class defines a logger for displaying the logs from Python
        scripts, in console log and file log.</para>

        <para>For console log, the logger has:</para>

        <itemizedlist spacing="compact">
          <listitem>
            <para>Default severity: <literal>INFO</literal></para>
          </listitem>

          <listitem>
            <para>Format of the logs: <literal>[datetime] [severity]
            message</literal></para>
          </listitem>
        </itemizedlist>

        <para>For file log, the logger has:</para>

        <itemizedlist spacing="compact">
          <listitem>
            <para>Logs path: <literal>log/debug.log</literal></para>
          </listitem>

          <listitem>
            <para>Default severity: <literal>DEBUG</literal></para>
          </listitem>

          <listitem>
            <para>Format of the logs: <literal>[severity]
            [name_of_Python_script] message</literal></para>
          </listitem>
        </itemizedlist>
      </section>
    </section>
  </section>

  <section id="AFTH_test">
    <title>Test Harness</title>

    <para>The Test Harness sources are in the
    <literal>&lt;Automation-installerdir&gt;/test_harness</literal>
    directory.</para>

    <section id="indiv_ansible_playbooks">
      <title>Individual Ansible Playbooks</title>

      <para>The Ansible based Test Harness represents an example of
      structuring the files needed for creating automated test cases using the
      Enea Edge Automation, and provides a way to implement them.</para>

      <para>The <filename>ansible.cfg</filename> file contains an example of
      the Ansible default configuration. The default value for
      <literal>stdout_callback</literal> is set to
      <literal>selective</literal>, to print only certain tasks. It is
      recommended to switch to <literal>debug</literal> when a test fails. By
      setting the parameter <literal>any_errors_fatal</literal> to
      <literal>True</literal>, task failures are considered fatal errors and
      the play execution stops.</para>

      <para>All the Playbooks that execute Automation Framework Python modules
      run on <literal>localhost</literal>. New entries have to be created for
      direct communication over SSH with the boards.</para>

      <para>The <filename>setup_env.sh</filename> script sets up the
      <literal>testHarness</literal> test environment by creating the
      <literal>testHarness-venv</literal> Python virtual environment,
      executing requests needed by Automation Framework Python modules, and
      installing Ansible. The Ansible package version is 2.9.6.</para>

      <para>The <literal>test_harness</literal> directory contains all the
      implemented Ansible Playbooks. This directory contains the
      <filename>check_error.yml</filename> Playbook and many subdirectories,
      each subdirectory representing an Enea Edge Management module.</para>

      <para>The <filename>check_errors.yml</filename> Playbook checks the
      Python output and returns success or fail results. This file is imported
      in all playbooks from the <literal>test_harness</literal> directory and
      it cannot be run standalone.</para>

      <para>According to their functionality, the Ansible Playbooks that refer
      to offline configuration are in the <literal>OfflineConfig</literal>
      directory, the ones that refers to <literal>CustomScript</literal> are
      in the <literal>CustomScripts</literal>, and so on.</para>

      <para>Each Ansible Playbook has a help menu for:</para>

      <itemizedlist spacing="compact">
        <listitem>
          <para>Returning the syntax, and examples for running the
          Playbook.</para>
        </listitem>

        <listitem>
          <para>Warning if the input parameters are wrong or not enough. The
          input parameters are called <literal>extra-vars</literal> in Ansible
          playbooks.</para>
        </listitem>
      </itemizedlist>

      <para>The help menu is activated when the Playbook is run without any
      parameters.</para>

      <para><emphasis role="bold">Example</emphasis>:</para>

      <orderedlist>
        <listitem>
          <para>Display the help menu for
          <filename>addDataPlaneOvsBridge.yml</filename>:</para>

          <programlisting>ansible-playbook test_harness/uCPEDevice/addDataPlaneOvsBridge.yml

This playbook runs 'addDataPlaneOvsBridge' method from uCPEDeviceHandler module

    The Python module will be run as:

    Usage: uCPEDeviceHandler.py [OPTIONS] [PARAMETERS]...

    Options:
      -v, --verbose           Get info about the methods and parameters
      -d, --device_name TEXT  The uCPE Device name
      -m, --method TEXT       The atomic operation you want to run
      -f, --config_file TEXT  The config file for NIC or bridges (optional
                              argument)

      -o, --display_output    Display output of the method
      --help                  Show this message and exit.

Usage:
    ansible-playbook test_harness/uCPEDevice/addDataPlaneOvsBridge.yml -e 
    "device=&lt;device_name&gt; bridge_config_file=&lt;bridge_config_file&gt;"
    ansible-playbook test_harness/uCPEDevice/addDataPlaneOvsBridge.yml -e 
    "device=&lt;device_name&gt; bridge_name=&lt;bridge_name&gt; bridge_type=integration"
    ansible-playbook test_harness/uCPEDevice/addDataPlaneOvsBridge.yml -e 
    "device=&lt;device_name&gt; bridge_name=&lt;bridge_name&gt; bridge_type=communication"
    ansible-playbook test_harness/uCPEDevice/addDataPlaneOvsBridge.yml -e 
    "device=&lt;device_name&gt; bridge_name=&lt;bridge_name&gt; bridge_type=communication 
    interfaces=&lt;interfaces&gt;"</programlisting>
        </listitem>

        <listitem>
          <para>Run the <filename>addDataPlaneOvsBridge.yml</filename>
          playbook:</para>

          <programlisting>ansible-playbook test_harness/uCPEDevice/addDataPlaneOvsBridge.yml -e 
"device=inteld1521-17 bridge_config_file=sfc_br.json"
ansible-playbook test_harness/uCPEDevice/addDataPlaneOvsBridge.yml -e 
"device=inteld1521-17 bridge_config_file=lan_br.json"
ansible-playbook test_harness/uCPEDevice/addDataPlaneOvsBridge.yml -e 
"device=inteld1521-17 bridge_name=sfc_br bridge_type=integration"
ansible-playbook test_harness/uCPEDevice/addDataPlaneOvsBridge.yml -e 
"device=inteld1521-17 bridge_name=wap_br bridge_type=communication"
ansible-playbook test_harness/uCPEDevice/addDataPlaneOvsBridge.yml -e 
"device=inteld1521-17 bridge_name=lan_br bridge_type=communication 
interfaces=eno4"
ansible-playbook test_harness/uCPEDevice/addDataPlaneOvsBridge.yml -e 
"device=inteld1521-17 bridge_name=lan_br bridge_type=communication 
interfaces=eno4,eno5"</programlisting>
        </listitem>
      </orderedlist>

      <para>Each Ansible Playbook from the <literal>test_harness</literal>
      directory represents an atomic operation, a basic functionality that is
      performed on the Enea Edge Management application at a specific period
      of the time. They can be sequentially run or they can be imported into
      other playbooks for creating complex scenarios.</para>

      <para><emphasis role="bold">Example:</emphasis></para>

      <para>To instantiate a VNF, the following operations have to be
      performed: connect to the uCPE Device, bind NICs, create an OVS bridge,
      create a VNF descriptor, and instantiate the VNF on the device. All
      these operations can be run Playbook after Playbook using the
      <literal>*.yml</literal> files from the <literal>test_harness</literal>
      directory.</para>
    </section>

    <section id="test_scenario">
      <title>Test Scenario</title>

      <para>All the individual Playbooks can be used as imported Playbooks in
      complex test scenarios.</para>

      <para>The complex scenarios are defined in:
      <literal>modules/enea/scenario</literal>.</para>

      <para>The test scenarios are split into the following:</para>

      <itemizedlist spacing="compact">
        <listitem>
          <para>Functionalities to be tested and used: the
          <literal>CustomScripts, OfflineConfig, ovsTests</literal>
          directories.</para>
        </listitem>

        <listitem>
          <para>Service Creation and Lifecycle: the
          <literal>chainedVNFsService</literal> directory.</para>
        </listitem>

        <listitem>
          <para>VNF Deployment and Lifecycle: the
          <literal>fortigateFWService</literal> directory.</para>
        </listitem>
      </itemizedlist>

      <para>For each test scenario, the <literal>README</literal> file
      contains:</para>

      <itemizedlist>
        <listitem>
          <para>Preconditions:</para>

          <itemizedlist spacing="compact">
            <listitem>
              <para>The configuration files to be updated</para>
            </listitem>

            <listitem>
              <para>The VNF images to be copied</para>
            </listitem>

            <listitem>
              <para>The license file needed from the provider and added to a
              specific path, etc.</para>
            </listitem>
          </itemizedlist>
        </listitem>

        <listitem>
          <para>Running procedures:</para>

          <itemizedlist spacing="compact">
            <listitem>
              <para>The <literal>ansible-playbook</literal> commands for setup
              the configuration</para>
            </listitem>

            <listitem>
              <para>Testing the configuration</para>
            </listitem>

            <listitem>
              <para>Cleaning up the configuration</para>
            </listitem>
          </itemizedlist>
        </listitem>
      </itemizedlist>

      <para>The test scenarios have the <filename>variable.yml</filename> file
      that contains the input parameters for the Playbooks. These variables
      can be reused when the same setup is run on another device.</para>

      <para><emphasis role="bold">Example:</emphasis></para>

      <para>For the <literal>fortigateFWService</literal> scenario, the
      <filename>variable.yml</filename> file has the following content:</para>

      <programlisting>vnf_image_path: "modules/enea/VNF_images/fortios.qcow2"
vnfd_config_file: "modules/enea/config/VNF/fortigateImage/fortigateImage.json"
vnfd_name: "fortigateImage"
vnfi_config_file: "modules/enea/config/VNF/fortigateImage/fortigateFWInstance.json"
vnfi_name: "fortigateFWInstance"</programlisting>
    </section>
  </section>

  <section id="AFTH_pyton">
    <title>Python Unit-Test Suite</title>

    <para>The <literal>unit-test</literal> suite is implemented in the
    <literal>unit_tests</literal> directory.</para>

    <para>The <literal>unit-test</literal> suite contains the
    <literal>unit-test</literal> class defined in
    <filename>unittestSuite.py</filename>, and examples of JSON configuration
    files that can be used for the execution of AF Python classes from the
    <literal>automation_framework</literal> directory.</para>

    <para>The Python <literal>unit-test</literal> class defined in the
    <filename>unittestSuite.py</filename> script provides a way to automate
    the execution of specific test cases for each supported Python
    script.</para>

    <para>This class requires a test suite configuration JSON file that
    contains a dictionary list of the Python scripts to be processed. Each
    dictionary contains the path of the Python script to be loaded and the
    path to the file describing the test cases to be performed against the
    designated script.</para>

    <para>Python <literal>unit-test</literal> suite examples are in the
    <literal>unit_tests/scenario</literal> directory.</para>

    <para>Each scenario has 3 parts:</para>

    <itemizedlist spacing="compact">
      <listitem>
        <para><literal>README</literal> - explains the prerequisites needed
        before running the Python <literal>unit-test</literal> suite.</para>
      </listitem>

      <listitem>
        <para><literal>config</literal> - contains a JSON file for each
        functionality that is used in the specified scenario. The JSON files
        have two keys:</para>

        <itemizedlist spacing="compact">
          <listitem>
            <para>name: The description of the functionality.</para>
          </listitem>

          <listitem>
            <para>args: The arguments of the Python module.</para>
          </listitem>
        </itemizedlist>
      </listitem>

      <listitem>
        <para><literal>JSON</literal> - used for running the scenario. Each
        JSON file contains the calls to the JSON files from the
        <literal>config</literal> directory, and has two keys:</para>

        <itemizedlist spacing="compact">
          <listitem>
            <para>config: The JSON file from the <literal>config</literal>
            directory that is used.</para>
          </listitem>

          <listitem>
            <para>module: The Python module that is run.</para>
          </listitem>
        </itemizedlist>
      </listitem>
    </itemizedlist>

    <para>Steps for running the Python unit-test suite on the Enea Edge
    Management application are provided in the <literal>README</literal> file
    from scenario in use.</para>
  </section>
</chapter>