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

Georgy Okrokvertskhov gokrokvertskhov at mirantis.com
Mon Jul 6 18:47:17 UTC 2015


Hi Kate,

MuraPL has a concept of exceptions. Unit testing will be important to make
sure that workflows behaves correctly in exceptions situations. How will be
this addressed int he testing framework? Will you have some specific
assertions like python unit testing framework?

Thanks
Gosha

On Mon, Jul 6, 2015 at 9:02 AM, Ekaterina Chernova <efedorova at mirantis.com>
wrote:

> Folks,
>
> 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:
>
> Namespaces:
>     =: io.murano.apps.foo.tests
>     sys: io.murano.system
>     pckg: io.murano.apps.foo
>
> Extends: io.murano.tests.TestFixture
>
> Name: FooTest
>
> Methods:
>     initialize:
>         Body:
>             *# Object model can be loaded from json file, or provided
> directly in murano-pl code as a yaml insertion.*
> *            # - $.appJson:
> new(sys:Resources).json('foo-test-object-model.json')*
>             - $.appJson:
>                 - ?:
>                     type: io.murano.apps.foo.FooApp
>                   name: my-foo-obj
>                   instance:
>                       ?:
>                           type: io.murano.resources.Instance
>                       ...
>
>     setUp:
>         Body:
>             - $.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)
>
>
>     testFooApp:
>         Body:
>             - $.env.deploy()
>             - $.assertEqual(true, $.myApp.getAttr('deployed'))
>
>     mockInstanceDeploy:
>         Arguments:
>             - mockContext
>         Body:
>             - 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
> > wrote:
>
>> 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
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150706/4065a45d/attachment.html>


More information about the OpenStack-dev mailing list