Open Stack

Hi Gosha,

In my understanding, the base test class (io.murano.tests.TestFixture)
should have something like assertRaises method, similar to the one in python

--
Regards,
Alexander Tivelkov

On Mon, Jul 6, 2015 at 9:47 PM, Georgy Okrokvertskhov <
gokrokvertskhov at mirantis.com> wrote:

> 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
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150707/58724de7/attachment.html>