# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
Description: Open CAFE Core
| |_ |
| :-) |_| |
=== CAFE Core ===
OpenCAFE, the Open Common Automation Framework Engine, is designed to be used
as the base for building an automated testing framework for API and other
It is designed to support all kinds of testing methodologies, such as unit,
functional and integration testing, using a model-based approach.
Although the engine is not designed with performance or load testing in mind,
as it prioritizes repeatability and (verbose) logging over performance, it can
be used to that end.
Source code is available at https://github.com/openstack/opencafe
Supported Operating Systems
Open CAFE Core has been developed primarily on and for Linux, but supports
installation and execution on BSD and other \*nix's, as well as OS X and
modern Windows. It can be installed from pypi via pip or from source.
**It is recommended that you install OpenCAFE in a python virtualenv.**
From pypi via pip
$ pip install opencafe
$ git clone https://github.com/openstack/opencafe.git
$ cd opencafe
$ python setup.py install
Post-install, the ``cafe-config`` cli tool will become available.
It is used for installing
plugins and initializing the engine's default ``.opencafe`` directory.
OpenCAFE uses a set of default locations for logging, storing
test configurations, test data, statistics, and the like; all of which are
set in, and read from, the ``engine.config`` file (in order to make it easy
for the end user to override the default behavior). The ``engine.config``
file, and the directories it references, can be created on demand by running:
This will create a directory named ``.opencafe`` in the user's home
directory, or in the case of a python virtualenv, in the virtualenv root
The ``cafe-config plugins`` command is used to list and install plugins.
$ cafe-config plugins list
* Available Plugins
$ cafe-config plugins install http
* Installing Plugins
Package Structure Overview
Provides tools for logging and reporting.
This namespace should be used by plugins to add logging and reporting features.
Used by the ``cafe-config`` cli tool for setting up new installations of opencafe.
Houses various test runner wrappers and supporting tools.
This namespace should be used by plugins to add new test runner support.
Includes the base classes that OpenCAFE implementations will use to create behaviors, configs, clients and models.
This namespace should be used by plugins to add new clients.
Historically contained all modules that reference external resources to OpenCAFE. Currently acts only as a namespace for backward compatability with some plugins.
Following are some notes on Open CAFE lingo and concepts.
Although the engine can serve as a basic framework for testing, it's meant to be used as the base for the implementation of a product-specific testing framework.
Anything that's being tested by an implementation of Open CAFE Core. If you would like to see a reference implementation, there is an `Open Source implementation <https://github.com/stackforge>`_ based on `OpenStack <http://www.openstack.org/>`_.
* Client / Client Method
A **client** is an "at-least-one"-to-"at-most-one" mapping of a product's functionality to a collection of client methods. Using a `REST API <https://en.wikipedia.org/wiki/Representational_state_transfer>`_ as an example, a client that represents that API in CAFE will contain at least one (but possibly more) method(s) for every function exposed by that API. Should a call in the API prove to be too difficult or cumbersome to define via a single **client method**, then multiple client methods can be defined such that as a whole they represent the complete set of that API call's functionality. A **client method** should never be a superset of more than one call's functionality.
A **behavior** is a many-to-many mapping of client methods to business logic, functioning as compound methods. An example behavior might be to POST content, perform a GET to verify the POST, and then return the verified data
A **model** can be many things, but generally is a class that describes a specific data object. An example may be a collection of logic for converting an XML or JSON response into a data object, so that a single consumer can be written to consume the model.
This is meant to be a convenience facade that performs configuration of clients and behaviors to provide configuration-based default combinations of different clients and behaviors.
Classifier: Development Status :: 4 - Beta
Classifier: Intended Audience :: Developers
Classifier: Natural Language :: English
Classifier: License :: Other/Proprietary License
Classifier: Operating System :: POSIX :: Linux
Classifier: Programming Language :: Python
Classifier: Programming Language :: Python :: 2.7
TODO: Brief introduction on what you do with files - including link to relevant help section.