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 <efedor...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev