Have questions? Stuck? Please check our FAQ for some common questions and answers.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

Test files

You can see test files 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 set of files defined below:

.params - This file contains user defined variables for the test case. Also specify the order of which test cases to run.

.topo - This file defines all the components and options that TestON will use to execute its test. The machine's user name, password, IP addresses, drivers, and/or Mininet's topology would be specified in this file. ( Please use the exact syntax/format in the topo file. The space character in the xml tags is important even though you are not defining anything in the tag Eg. <COMPONENTS> </COMPONENTS>)

.py - This is where all of the test cases are written. It calls upon functions implemented in the respective drivers to create a progression of events that produces some sort of pass/fail outcome.

SAMPstartTemplate_1node and SAMPstartTemplate_3node tests

These tests demonstrate several simple actions using TestON. The test is successful if all testcases succeed.

  • CASE0:   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: Start 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: Configure fwd app and run pingall

Params File

Below is the SAMPstartTemplate_1node.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>
    <CASE0>
        <gitPull>False</gitPull> # False or True
        <gitBranch>master</gitBranch>
    </CASE0>

    <CASE1>
        <NodeList>OC1,OC2,OC3</NodeList>
        <SleepTimers>
            <onosStartup>60</onosStartup>
            <onosCfg>5</onosCfg>
            <mnStartup>15</mnStartup>
            <mnCfg>10</mnCfg>
        </SleepTimers>
    </CASE1>

    <CASE10>
        <numNodes>1</numNodes>
        <Apps>
            org.onosproject.openflow,org.onosproject.fwd
        </Apps>
        <ONOS_Configuration>
            <org.onosproject.net.intent.impl.compiler.IntentConfigurableRegistrator>
                <useFlowObjectives>true</useFlowObjectives>
            </org.onosproject.net.intent.impl.compiler.IntentConfigurableRegistrator>
        </ONOS_Configuration>
    </CASE10>

    <CASE11>
        <path>~/OnosSystemTest/TestON/tests/SAMP/SAMPstartTemplate2_1node/Dependency/</path>
        <topo>newFuncTopo.py</topo>
    </CASE11>

    <CASE12>
    </CASE12>

    <CASE22>
    </CASE22>
 
    <CASE32>
    </CASE32>
</PARAMS>

 

The <testcases> tag defines the order in which the test cases in the .py file are executed. <PARAMS> and <testcases> are mandatory tags and the tags are case sensitive.

Topo File

Below is the SAMPstartTemplate_1node.topo file:

 

<TOPOLOGY>
 
    <COMPONENT>
 
    <!--
        This is a list of all components and their handles in the test setup.
        Even with some handles not used in test cases, we want to define
        all onos cells here, for cases to set up onos cluster.
    -->
 
        <ONOSbench>
            <host>localhost</host>
            <user>sdn</user>
            <password>rocks</password>
            <type>OnosDriver</type>
            <connect_order>1</connect_order>
            <COMPONENTS>
                <home></home> #defines where onos home is
            </COMPONENTS>
        </ONOSbench>
 
        <ONOScli1>
            <host>OC1</host>
            <user>sdn</user>
            <password>rocks</password>
            <type>OnosCliDriver</type>
            <connect_order>2</connect_order>
            <COMPONENTS>
            </COMPONENTS>
        </ONOScli1>
 
        <Mininet1>
            <host>OCN</host>
            <user>sdn</user>
            <password>rocks</password>
            <type>MininetCliDriver</type>
            <connect_order>5</connect_order>
            <COMPONENTS>
                <home>~/mininet/custom/</home>
            </COMPONENTS>
        </Mininet1>
 
        <ONOSrest1>
            <host>OC1</host>
            <port>8181</port>
            <user>onos</user>
            <password>rocks</password>
            <type>OnosRestDriver</type>
            <connect_order>6</connect_order>
            <COMPONENTS>
            </COMPONENTS>
        </ONOSrest1>
 
    </COMPONENT>
 
</TOPOLOGY>

 

The .topo file includes the log in info of the machine that the ONOS and Mininet will be run. In this example, the test runs using two VM machine with host IP, user name, password as well as the driver that will be used are defined for each of the component. The <connect_order> tag is the connection order that the TestON will execute. The formatting of 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. The <type> tag is use to specify which driver the component will use, the driver name is case sensitive. The <args> tag in the MIninet component is necessary and should be kept even though it has empty arguments. In the Topo file, all the tags are necessary but the driver specific tags can be placed between the components tags.

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

Python file

The python file defines all the test cases for the test. In the SAMPstartTemplate_1node 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 /TestON/bin/codecheck. All of the TestON test follow the pep8 coding style.

Every case results in your test should be asserted at the end of the case using TestON utilities class. There are different kinds of assert: equals,matches,greater,lesser. Equals assert is used most of the time because it is efficient and easy to use. Below is an example of assert in case 10:

SAMPstartTemplate_1node.py.
main.step( "Start ONOS cluster with basic (drivers) app.")
onosClusterIPs = []
for n in range( 1, numNodes + 1 ):
    handle = "main.ONOScli" + str( n )
    onosClusterIPs.append( eval( handle ).ip_address )

stepResult = main.ONOSbench.startBasicONOS(nodeList = onosClusterIPs, opSleep = 200 )
utilities.assert_equals( expect=main.TRUE,
                         actual=stepResult,
                         onpass="Successfully started basic ONOS cluster ",
                         onfail="Failed to start basic ONOS Cluster " )

Logs and report files

Three ways to specify the log directory path:

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

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

  1. test_name_time.log - Detailed verbose log of 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 created your test cases, you can now run your test by following the tutorial on how to run TestON. You can also improve your test by modifying the current TestON drivers or create your own test specific drivers. Check TestON Drivers 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.

  • No labels