Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
Architecture Overview
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.
- TestON/Core: The TestON core is where the test is parsed and executed. It is also where the test components are initialized and logging happens. Because the TestON core handles the parsing of the test cases, exceptions will be be thrown from here rather than the testname.py where the exception probably originated. This is why it is a good idea to incase your code with try-except blocks to make it easier to debug.
- Drivers: The python driver files are a collection of functions that belong to a specific test component, e.g., Mininet1 or ONOScli1. Each function performs a single component’s functionality or some variation of it. For example, there exists a Mininet driver function that calls the pingall command in Mininet and handles all the possible exceptions that might occur with this command. Similar to a dependency file, these are helper or wrapper functions that are commonly used throughout our tests. The main advantages behind a driver function are to encapsulate the components functionality, hide the tediousness of pexpect, and reduce duplicate code. If you are looking to test a specific functionality of ONOS=
Test Suite 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 is a custom file in which commonly configured variables can be placed in order to modularize the test cases.
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: