Introduction
General Guidelines and Structure
Robot Framework itself provides a good set of basic guidelines for writing good tests. You can read it here. The rest of this generally guide generally assumes you are familiar with this, as well as writing Robot Framework and python.
ONAP basically follows the structure represented at this link and the image linked below
The robot framework layer is managed for you and you should install whatever the setup.sh file has as any other version could cause issues with compatibility.
ONAP Robot Project Structure
Folder Structure
`-- robot
|-- assets
| |-- keys
| |-- templates
| |-- aai
| |-- vid
| `-- etc
|-- library - any python libraries needed to run tests are installed here (you dont edit these directly!)
| `-- eteutils - this is the robot code we write in the python testing utils project aka robotframework-onap. Put any python code libraries we write in there, but do not edit in here
|-- resources
| |-- aai
| |-- vid
| `-- etc
`-- testsuites - put any robot test suites we write in here
Assets
You should put anything you need as input like json files, cert keys, heat templates and templates. You should include subfolders for each component.
Two special folders are keys (put any private keys used in testing in here, you should NOT include keys used anywhere but testing, because they are here they are not secure.) and templates (put any json templates in here)
Resources
You should put any robot resource files aka reusable keywords we write in here, you should include subfolders for each component. These should be written in as reusable a manner as possible as they are meant to be keywords that provide a specific functionality, and if that functionality needs enhancement it should be added to the main keyword. Resources should be a useful library for all the test cases to call upon!
Tag Structure
Robot uses tags to separate out test cases to run. below are the tags we use
- health - use this for test cases that perform a health check of the environment
- core, small, medium - use these for test cases that require a certain level of ecomp
- dev-<helm-component> - use this tag to filter test cases that should be run only if this component exists
- api - this tag is for tests that use the msb api
- csit_<component>_<whatever> - this tag is used to define specific tests. this lets you run certain tests in the csit phase of your project.
Branching Structure
Repository Name: testsuite