Page tree

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

Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 6 Next »

Interested in testing ONOS? Then you're in the right place - here are some basic tutorial on TestON, a test platform for testing ONOS.

TestON for ONOS: Paxterra’s TestON is made out of a set of drivers that connect to various components. In our case, these components will be ONOS, and mininet and can be pointed to either the same or different IP addresses. TestON manipulates these components through a set of ssh handles it creates using python’s pexpect. The test structure is comprised of a set of different tests, each with a number of test-cases inside. These test-cases each return a pass/fail result and can stand alone in theory. However more complete tests can be created by running multiple test-cases in series, which will return a percentage pass/fail result of all the containing test-cases. There will be certain test-case combinations that make more sense then others, and they will be placed in a sensible order, but in the end it is up to the user to determine logical sequences that produce meaningful data.

File Structure: There are three main files that define a specific test in TestON:

  • Topology file ( .topo ) This file defines all the components and options that TestON will use to execute its test. For example the topo file would include the login info and mininet parameters for the machine that was going to host the mininet for the test. At the beginning of the test, TestON will automatically connect all of these components.

  • Parameter file ( .params ) This file stores all of the variables that the test will call upon to run the test such as which test-cases to run. This lets you tweak wait times and other values to tune the test to your needs all in one file.

  • Python file ( .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.

You can start by:

 

  • No labels