Page History

Table of Contents

...

 Marvin ↓ - our automation framework is a Python module that leverages the abilities of python and its multitude of libraries. Tests written using our framework use the unittest module under the hood. The unittest module is the Python version of the unit-testing framework originally developed by Kent Beck et al and will be familiar to the Java people in the form of JUnit. The following document will act as a tutorial introduction to those interested in testing CloudStack with python.

...

 This document does not cover the python language and we'll be pointing the reader instead to explore some tutorials that are more thorough on the topic. In the following we will be assuming basic python scripting knowledge from the reader. The reader is encouraged to walk through the steps after he/she has their environment setup and configured.

Environment

Developers

If you are a developer the cloudstack development environment is sufficient to get started

...

• All tests must be written with the perspective of the API. UI directions are often confusing and using the rich API often reveals further test scenarios. You can capture the API arguments using cloudmonkey/firebug.
• Tests should be generic enough to run in any environment/lab - under any hypervisor.** If this is not possible then it is appropriate to mark the test with an @attr attribute to signify any specifics. eg: @attr(hypervisor='vmware') for runs only on vmware
• Every resource should be creatable in the test from scratch.** referring to an Ubuntu template is probably not a good idea. Your test must show how to fetch this template or give a static location from where the test can fetch it.
• Do not change global settings configurations in between a test. Make two separate tests for this. All tests run against one given deployment and altering the settings midway is not effective

...

• Verifying status of resources within hypervisors is fine. Most hypervisors provide standard SSH server access
• Your tests should include the complete command and its expected output. ** e.g. iptables -L INPUT -# to list the INPUT chain of iptables
• If you execute multiple commands then all of them should be chained together on one line** e.g: service iptables stop; service iptables start #to stop and start iptables
• Your script must execute over ssh because this is how Marvin will execute it** ssh <target-backend-machine> "<your script>" #should return the output of your script
  • move the credential specific information into the deployment config file and/or use a standard credential
• Most external devices like F5/ NetScaler have ssh open to execute commands. But you must include the command and its expected output in the test as not everyone is aware of the device's CLI
• If you are using a UI like vCenter to verify something most likely you cannot automate what you see there because there are no ASLv2 licensed libraries for vmware/esx as of today.

...