Previous topic

Update

Next topic

Integration Procedures

Auto-Test

Test tools allow you to test some operations with your application. This document explains how to run a test based on the pytest framework.

Prerequisites

The platform you use for testing your integration package must meet the Prerequisites stated in the deployment phase.

Prepare Auto-Test Environment

The OSS management node is installed on a RHEL or CenOS operating system that allow installing packages through the yum package manager. On a test system, you should add the python-setuptools package and then use the easy_install Python package manager to install the pytest package.

The following steps make your platform ready for testing.

  1. Install the python-setuptools package:

    # yum install python-setuptools

  1. Install the pytest framework:

    # easy_install pytest

Once you have done it, the management node is ready to run your application test.

Run Application Test

On the OSS management node, run the predefined script to test your APS package as follows.

  1. Create a folder and place the following two files into it:

    If you do not have your own APS package, use the sample package to study the auto-test script.

  2. Enter inside the folder and run the auto-test script:

    # pytest -vv -x test_app.py

The test_app.py script will discover the package with the app.zip extension and apply its tests to it. If all tests passed, you will see the following print-out:

=============================== test session starts =======================================
platform linux2 -- Python 2.7.5, pytest-3.0.7, py-1.4.33, pluggy-0.4.0 -- /usr/bin/python2
cachedir: .cache
rootdir: /root/autotest, inifile:
collected 6 items

test_app.py::TestApp::test_01_import PASSED
test_app.py::TestApp::test_02_instance PASSED
test_app.py::TestApp::test_03_st PASSED
test_app.py::TestApp::test_04_subscription PASSED
test_app.py::TestApp::test_05_hold PASSED
test_app.py::TestApp::test_06_terminate PASSED

================================ 6 passed in 17.75 seconds ================================

If one of the tests fails, the script stops at this test and print out the description of the issue in details.

The auto-test script contains the following sequence of tests that you can extend if necessary:

  1. test_01_import imports the APS package from the current folder.

  2. test_02_instance installs an APS connector and initiates an APS application instance on the end-point host using the Docker image you have created earlier in the deployment phase.

  3. test_03_st creates a service template with two main resource types (APS application instance and management context) as defined in the dictionary aiw_template inside the test_app.py script.

  4. test_04_subscription creates a subscription from the new service template.

  5. test_05_hold disables and then enables the subscription.

  6. test_06_terminate terminates the subscription.

If you edit this auto-test script or create your own, pay attention to the aiw_template dictionary. It defines the product components to be created in the platform using a syntax similar to one explained in the Product Initialization document.

Effects in Control Panel

In the provider control panel, you will find the consequences of the tests you have executed.

  • Operations > Tasks shows all tasks activated by the tests.

  • Services > Applications shows the imported APS package (APS application). If you run the tests multiple times, only one package with a specified application ID and version can be imported.

  • If you open the imported application, the Instances tab shows a list of APS application instances, one per each successful test_02_instance test.

  • If you open the imported application, the Resource Types tab shows a list of resource types. Each time the test_03_st test completes successfully, a new set of resource types appears even if their names were not changed in the aiw_template dictionary.

  • Products > Service Templates shows a list of service templates. Each time the test_03_st test completes successfully, a new service template appears even if its name was not changed in the aiw_template dictionary.

You can use the test results by creating additional resource types, including them into one of the remained service templates, and then creating subscriptions from the modified service template.

Conclusion

The testing procedure explained here demonstrates you one more important direction in automating the development process and ensuring the reliability of the integration package.