Testing Alfresco extensions (no, it’s not about jUnit) 07/11/2013 Alexey Ermakov / ITD Systems Hello everyone. Let me introduce myself. My name is Alexey Ermakov, I'm one of the core developers of Alvex – the Alfresco-based product that we're building.

Testing Alfresco extensions (no, it’s not about jUnit) 07/11/2013 Alexey Ermakov / ITD Systems Today I would like to talk to you about the way one tests Alfresco extensions. As far as I know at the moment there is no testing best practices defined by vendor, so everyone tests the way he likes. That’s why we decided to build our small testing framework.

What’s the target? REST APIs tests UI tests complex behavioral scenarios easy-to-write tests So what do we want to do with framework? Basically, we are not interested in classic unit tests since they allow you to test a very limited number of things. We want to test our REST APIs and custom Uis with complex behavioral scenarios that must be easy-to-write.

Why? There’s Alfresco SDK and jUnit that already allow you to run tests with repository embedded to your Java code. Well, you might want to ask a question: «Why do you need to reinvent the wheel instead of using existing frameworks? There are already Alfresco SDK and jUnit that allow you to run your test with Alfresco repository embedded». And you will be right.

Because we can! But, the answer is quite simple: “Because we can!”  But talking seriously, that’s because we don’t want to write unit tests, we do not want to use Java too. So, what do we offer?

What’s inside? Python as the main tests language Proboscis as a core testing framework Selenium as a web browser emulator The idea behind is to use easy-to-learn Python as tests language. As a core testing framework we use proboscis that is very similar to both Test-NG and jUnit. For UI tests we use Python bindings for Selenium engine

But where is your framework? Repository tests: Python wrappers for REST calls Out-of-the-box implementation for few standard REST APIs Now let’s see what framework offers. For repository tests it offers you predefined Python wrappers for REST calls so you will need to care about Alfresco communication over HTTP. Moreover it defines few REST-based implementations of standard APIs.

Example from pyalfresco import alfresco from proboscis.asserts import assert_equal alf = alfresco.Alfresco() assert_equal( alf.get_person('admin').firstName, 'Administrator‘) Let’s see it by example. So here you can see invocation of people service APIs that are exposed to Python through the REST. It’s absolutely transparent – there is nothing to do with HTTP requests in the code.

Example def get_task(self, id): return WrapperObject( self, **self.repo_get_json( 'api/task-instances/%s' % id ) In case you feel predefined APIs are not enough for you it’s very easy to extend a list of available APIs. Just get json from the right URL and WrapperObject will do the rest of job for you.

OK, what’s about UI tests? Predefined classes and decorators to run tests only for specific browsers One of the most interesting parts of framework is the way it allows you to write UI tests. There’s a number of predefined classes and decorators to help you to run tests only for specific browsers.

OK, what’s about UI tests? Predefined classes and decorators to run tests only for specific browsers Predefined APIs to interact with Alfresco Share forms system Another cool feature is ability to define Share forms in Python code and the interact with them the way you do it in browser. Ok, let’s again take a loop at a code sample to understand how it works.

Example from pyalfresco.tests import * @for_browsers(['ie', 'firefox']) class DashletTest(AlfrescoShareTest): pass By default all the UI tests you have will be run for every browser that is available. In case you want to limit testing scope, just declare test with @for_browsers decorator. After that test will be executed only for explicitly specified browsers.

Dashlet to test Now let’s move to the most fancy part, to UI testing. We have a dashlet like this that display list of workflows that user is permitted to launch. When one clicks the link a workflow start form opens.

Workflow start form This is the form. Mandatory fields have to be filled before form may be submitted. We have two mandatory fields – one with standard text control and one with custom control.

Testing dashlet class WorkflowShortcutsDashlet(AlfrescoShareObject): def locate(self): self.el = self.driver.find_element_by_css_selector( '.dashlet.workflow-shortcuts‘ ) First thing we need is to implement dashlet in our code. With Selenium it’s quite easy, we just use css selector to find base element we’re interested in. After that we can implement other dashlet logic like launching workflows etc.

Testing dashlet @test def locate_dashlet(self): self.perform_share_log_in('admin', 'admin') self.driver.get(URL + '/page/user/admin/dashboard') self.dashlet = WorkflowShortcutsDashlet( parent=None, driver=self.driver ) self.dashlet.locate() After dashlet completely defined in Python code we can easily use it in tests. We will skip details on dashlet implementation, let’s take a look on how to use it. Here we go: perform a login, open dashboard and try to locate dashlet.

Testing dashlet @test(depends_on=[locate_dashlet]) def launch_workflows(self): for w in self.dashlet.get_workflows().keys(): self.dashlet.launch_workflow(w) OK, we located dashlet on the dashboard. Now it’s time to use it and launch workflow. So we just iterate through all available workflows and click the corresponding link. Now it’s time to deal with workflow form.

Testing form <appearance> <field id="bpm:workflowDescription" /> <field id="bpm:assignee"> <control template="/orgchart-picker.ftl" /> </field> </appearance> Here’s the form configuration snippet. As I said before, we’re interested in filling two fields: standard text one and one with custom control, that shows popup dialog to pick an assignee.

Testing form f = AlfrescoShareWorkflowForm( workflow_id='activiti$wf', parent=self, fields=[ { 'name': 'bpm:workflowDescription', 'control': AlfrescoShareFormTextFieldControl }, ... ] ) Here is the code to create Python form representation. We configure it mostly the same as we do it for Share with xml config: we specify workflow id and list of fields we want to work with.

Testing form tffc = f.get_field_control('bpm:workflowDescription') tffc.set_text('DESCRIPTION') ocfc = f.get_field_control('bpm:assignee') ocfc.show_picker() ocfc.search('admin') ocfc.add_person('Administrator') ocfc.close_picker() f.submit() Now, when we defined form with fields and control we can easily interact with it using implemented APIs. So here we fill two fields: one by simple setting the text, other by using popup picker form.

Hm, what about complex tests? Create UI test Verify results with REST bindings Perform REST APIs tests … PROFIT!! Well, there is nothing special in framework to perform complex tests, but it’s very easy to implement large behavioral test by just combining described capabilities: UI tests, repository tests, Python REST bindings.

Roadmap More wrappers for REST APIs More predefined form controls Improvements to framework code Now I’m gonna say few words on project roadmap. We’re planning to continue project development by implementing more wrappers for REST APIs, python bindings for form controls and of course making improvements to framework code.

Stay in touch Follow us: @itdsystems Join the project: http://git.io/qzeE1Q That’s it. Here you can links for the project. Don’t hesitate to join us. Thank you for your attention.

Stay in touch Follow us: @itdsystems Join the project: http://git.io/qzeE1Q That’s it. Here you can links for the project. Don’t hesitate to join us. Thank you for your attention.