[openstack-dev] [Murano] Discuss simulated-execution-mode-murano-engine blueprint

Ekaterina Chernova efedorova at mirantis.com
Mon Jul 6 16:02:35 UTC 2015


I have specific topic to discuss: how murano test-fixture will look like
and how it can be run.

The idea is to implement a unit-testing framework, similar to regular
frameworks for python or other languages,
which will allow to define test fixtures in MuranoPL.
A Test fixture is a regular muranoPL class definition, which methods are
the test cases.
When such fixture is included into Murano application package the
deployment of application may be tested  without running actual VM's.

Here is how the test fixture may look like:

    =: io.murano.apps.foo.tests
    sys: io.murano.system
    pckg: io.murano.apps.foo

Extends: io.murano.tests.TestFixture

Name: FooTest

            *# Object model can be loaded from json file, or provided
directly in murano-pl code as a yaml insertion.*
*            # - $.appJson:
            - $.appJson:
                - ?:
                    type: io.murano.apps.foo.FooApp
                  name: my-foo-obj
                          type: io.murano.resources.Instance

            - $.env: $.createEnvironment($.appJson)   # creates an instance
of std:Environment
            - $.myApp: $.env.applications.where($.name='my-foo-obj').first()
            *# mock instance spawning*
            - mock($.myApp.instance, "deploy", "mockInstanceDeploy", $this)
            - mock(res:Instance, deploy, "mockInstanceDeploy", $this)

            - $.env.deploy()
            - $.assertEqual(true, $.myApp.getAttr('deployed'))

            - mockContext
            - Return:
               * # heat template*

io.murano.tests.TestFixture - is a base class, that contains set of
methods, needed in all the test-cases which inherit it, such as assertEqual
and other similar assertions.
All it contains a $.createEnvironment method which may be called at the
setUp phase (a method being run before each test case) to construct the
object model to run the test against.

Test developer will be able to mock some of the functions or method which
are out of the scope of the current test
(for example, interaction with other applications or classes from the
standard murano library, such as instance.deploy etc).
The mock will allow to override the actual method execution and provide the
expected output of the method.
The actual implementation of  mocking requires more thoughtful design,  so
I'll create a separate spec for it.

What do you think about the overall idea and the test syntax proposed above?

On Wed, Jun 3, 2015 at 5:15 PM, Ekaterina Chernova <efedorova at mirantis.com>

> Hi all!
> I'd like to discuss first implementation thoughts about this [1]
> blueprint, that we want to implement in Liberty.
> This feature is supposed to increase the speed of application development.
> Now engine interacts with API to get input task and packages.
> Items, planned to implement first would enable loading local task and new
> package, without API and Rabbit involved.
> After that simple testing machinery will be added to MuranoPL: mock
> support and simple test-runner.
> So user can test application methods as he wants by creating simple tests.
> Deployment parameters, such as heat stack and murano execution
> plan outputs
> may be set as returned value in tests.
> Finally, tests may be placed into a murano package for easier package
> verification and later modification.
> I'm going to write specification soon. But before, we need to prepare list
> of functions, that are needed to
> implement simple mocking machinery in MuranoPL.
> Please, leave your thoughts here or directly in the blueprint.
> Regards, Kate.
> [1] -
> https://blueprints.launchpad.net/murano/+spec/simulated-execution-mode-murano-engine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150706/b90f0c3b/attachment.html>

More information about the OpenStack-dev mailing list