Test files

You can see test files Test files are located in the /TestON/tests/ folder. The name of the test folder should be the name of the test as well as all the files. Each of the tests has a unique  Each test contains a set of files defined below:

• .params - This file contains user defined variables

...

• , as well as specifies the order of which test cases to run.
• .topo - This file defines

...

• the components and options that

...

• TestON will use to execute

...

• the test.

...

• User name, password, IP addresses, drivers, and/or a Mininet

...

• topology

...

• are specified in this file. (Please use the exact syntax/format in the .topo file. The space character in the xml tags is important even

...

• if nothing is defined in the tag. Eg. <COMPONENTS> </COMPONENTS>)
• .py - This is where

...

• test cases are written.

...

• Test cases call upon functions implemented in

...

• their respective drivers to create a progression of events that

...

• produce a pass/fail outcome.

PingallExample test

The test folder name is the name of the test, as well as the names of the .py, .params, and .topo files.

SAMPstartTemplate_1node and SAMPstartTemplate_3node tests:

These tests demonstrate several simple actions using TestONThis test uses pingall function to ping all the host in the network. The test is successful if all the hosts are reachabletest cases succeed.

• CASE1CASE0: Starts up ONOS, from pulling the latest code to running ONOS, also starts a Mininet topology from the .topo file. Reports success if ONOS did not start up correctly.
• CASE2: Assign mastership to controller. Reports success if all the switches are assigned to a controller.
• CASE3: Installs onos-app-fwd (reactive forwarding app) and does pingall. Reports success if all hosts are reachable.

Params File

•   Pulls ONOS code and builds ONOS.  This is usually skipped in the production environment for flexibility to handle testing different versions of ONOS
• CASE1:   Sets up global test variables and removes existing instances of ONOS in the test cell
• CASE2:   Reports errors, warnings, and exceptions in ONOS
• CASE10: Starts ONOS on the cell
• CASE11: Starts Mininet and assign mastership of switches to ONOS controllers
• CASE12: Tests some basic ONOS commands using the ONOS cli handle
• CASE22: Tests some basic ONOS commands using the REST API handle
• CASE32: Configures fwd app and run pingall

Params File:

Below is the SAMPstartTemplate_1nodeBelow is the PingallExample.params file:

<PARAMS>
    <!--
        CASE0: pull onos code - this case should be skipped on Jenkins-driven prod test
        CASE1: setup and clean test env
        CASE2: get onos warnings, errors from log
        CASE10: start a 1-node ONOS
        CASE11: Start Mininet and assign controllers
        CASE12: Sample case of using onos cli
        CASE22: Sample case of using onos rest
        CASE32: Configure fwd app
    -->

    <testcases>0,1,10,11,12,22,2,32</testcases>
    <GIT>
        <pull>False</pull>
        <branch>master</branch>
    </GIT>

    <CASE0>
    </CASE0>

    <CASE1>
        <NodeList>OC1</NodeList>
        <SleepTimers>
            <onosStartup>60</onosStartup>
            <onosCfg>5</onosCfg>
            <mnStartup>15</mnStartup>
            <mnCfg>10</mnCfg><PARAMS>
    <testcases>1,2,3</testcases>
    <ENV>
        <cellName>HA<</cellName>SleepTimers>
    </ENV>
CASE1>

    <CASE10>
        <numNodes>1</numNodes>
        <Apps>
            org.onosproject.openflow,org.onosproject.fwd
     <Git>True</Git>
   </Apps>
        <ONOS_Configuration>
            <org.onosproject.net.intent.impl.compiler.IntentConfigurableRegistrator>
                <useFlowObjectives>true</useFlowObjectives>
    <CTRL>
            <defaultFlowObjectiveCompiler>org.onosproject.net.intent.impl.compiler.LinkCollectionIntentObjectiveCompiler</defaultFlowObjectiveCompiler>
           <ip1>10.128.30.11</ip1> </org.onosproject.net.intent.impl.compiler.IntentConfigurableRegistrator>
        </ONOS_Configuration>
    </CASE10>

    <CASE11>
        <topo> mn --topo tree,3,3 </topo>
    </CASE11>
    <CASE12>
    </CASE12>
    <CASE22>
    <port1>6633</port1></CASE22>
    <CASE32>
    </CTRL>CASE32>
</PARAMS>

The <testcases> tag defines the order in which the test cases in the .py file are executed. The <cellName> is the name of the cell when setting up your environment <PARAMS> and <testcases> are mandatory, case sensitive tags.

Topo File:

Below is the PingallExampleSAMPstartTemplate_1node.topo file: 

<TOPOLOGY>
    <COMPONENT>
    <!--
        <ONOSbench>
This is a list of all components and their handles in  <host>10.128.30.10</host>the test setup.
        Even with some handles not used in test  <user>admin</user>cases, we want to define
        all onos cells here,  <password> </password>for cases to set up onos cluster.
    -->
        <type>OnosDriver</type><ONOScell>
            <connect_order>1</connect_order><host>localhost</host>  # ONOS "bench" machine
            <COMPONENTS> <<user>sdn</COMPONENTS>user>
            <<password>rocks</ONOSbench>

password>
            <ONOScli1><type>OnosClusterDriver</type>
            <host>10.128.30.10</host><connect_order>1</connect_order>
            <user>admin<<home></user>
home>   # defines where onos home is on the  <password> </password>build machine. Defaults to "~/onos/" if empty.
            <type>OnosCliDriver</type><COMPONENTS>
            <connect_order>2</connect_order>
         <cluster_name></cluster_name>  # Used as a prefix for cluster components. Defaults to 'ONOS'
       <COMPONENTS> </COMPONENTS>
        </ONOScli1>

        <ONOS1>
            <host>10.128.30.11</host><diff_clihost></diff_clihost> # if it has different host other than localhost for CLI. True or empty. OC# will be used if True.
            <user>sdn</user>    <karaf_username></karaf_username>
            <password>rocks</    <karaf_password></karaf_password>
            <type>OnosDriver</type>    <web_user></web_user>
            <connect_order>3</connect_order>
    <web_pass></web_pass>
              <COMPONENTS>  </COMPONENTS><rest_port></rest_port>
        </ONOS1>

        <prompt></prompt>
                <Mininet1>
<onos_home></onos_home>  # defines where onos home is on the target cell <host>10.128.30.9</host>machine. Defaults to entry in "home" if empty.
            <user>admin</user>
    <nodes> 1 </nodes>  # number of nodes in <password>the </password>cluster
            <type>MininetCliDriver<</type>COMPONENTS>
        </ONOScell>

        <connect_order>4</connect_order><Mininet1>
            <COMPONENTS><host>OCN</host>
            <user>sdn</user>
    #Specify     the Option for mininet<password>rocks</password>
            <type>MininetCliDriver</type>
     <arg1> --topo=tree,3,3 </arg1>
     <connect_order>2</connect_order>
           <arg2> </arg2><COMPONENTS>
                <arg3> <home>~/mininet/custom/</arg3>home>
                <controller> remote </controller><prompt></prompt>
            </COMPONENTS>
        </Mininet1>

    </COMPONENT>
</TOPOLOGY>

The .topo file includes the log in login info of the machine that the will run ONOS and Mininet will be run. In this example, the test runs using two VM machine virtual machines with host IP, user name username, password as well as the , and driver that will be used are defined for each of Mininet and ONOS components. The <type> tag specifies which driver the component will use. The  The <connect_order> tag is the connection order that the TestON will execute. The formatting of  In the .topo file must be followed correctly. The space character inside every empty tag indicates that a blank information will be passed along in the component otherwise the test would give an error , if that space character isn't there, and would stop the test. The <type> tag is use to specify which driver the component will use. The <args> tag in the MIninet component is necessary and should be kept even though have empty arguments., all tags are required, but driver specific tags may be reordered between the components tags.

NOTE: It is important to check the log in login info carefully for each component as incorrect information would result to in a test failure.

Python

...

File:

The python .py file defines all the test cases for the test. In the PingallExample and every other test in TestON, a utility class is called to assert each cases by the end of the case. Although not required, It is a good practice to follow a coding style in to your test scripts to improved readability of your code. Check out our built in code checker using pep8 coding style at  All of the TestON tests follow the PEP8 coding style.  Check out our built-in PEP8 code checker at /TestON/bin/codecheck. All of the TestON test follow the pep8 coding style.

Stuck? Found a bug? Questions?

Email us if you’re stuck, think you’ve found a bug, or just want to send some feedback. Please have a look at the guidelines to learn how to efficiently submit a bug report.

Logs and report files

Test case results should be asserted at the end of the case using the TestON utilities class.  There are four types of assertions: "equals", "matches", "greater", and "lesser". Below is an example of "equals" assertion in case 10:

main.step( "Start ONOS cluster with basic (drivers) app.")
stepResult = main.ONOSbench.startBasicONOS( nodeList=main.Cluster.getIps(),
                                            opSleep=200,
                                            onosUser=main.ONOScell.karafUser )
utilities.assert_equals( expect=main.TRUE,
                         actual=stepResult,
                         onpass="Successfully started basic ONOS cluster ",
                         onfail="Failed to start basic ONOS Cluster " )

Log and Report Files

There are two Three ways to specify the log directory path:

1. Default path will be the /logs/test_name_time/
2. Providing the Augmenting a command line option: --logdir "/path/to/logdirectory"
3. Parameterise Adding a parameter in the test_name .params file as : 'logdir' = '/path/to/logdirectory'

Note: If the log directory path is not specified, the default log path will be used: /TestON/logs/test_name_time/

After test execution of the test, there will be three types of logslog files:

1. test_name_time.log - Detailed verbose log of everythin everything that the script does.
2. test_name_time.rpt - Summary report of test case results.
3. component_name.SESSION - Log of all commands/APIs run on this component with response.

Exploring Further

Now that you have created your test cases, you can now run your test by following the tutorial on how to run TestON. You may also improve your test by modifying the current TestON drivers or create creating your own test specific drivers. Check the TestON Drivers article for more information.

Stuck? Found a bug? Questions?

Email us if you’re stuck, think you’ve found a bug, or just want to send some feedback. Please have a look at the guidelines to learn how to efficiently submit a bug report.