Not from the beginning

You know a lot of testing tools that can:

• Get steps in the Gherkin language immediately from what the user clicked?
• Create video instructions automatically, with subtitles, black jack and Elena ?)
• Create an * .feature file in English in the Romanian interface, for a user who speaks Italian?

About this is available and clearly (with pictures) in this article, do not switch ...

Introduction

This article is a review of the tool for testing 1C application solutions created in the depth of OpenSource called vanessa-automation . This project is a direct continuation of the widely known in narrow circles of the project vanessa-behavior (fork was created on version 1.1.131). By the way, there are other forks .

Context

However pleasant it would be to think that every reader of this article on habr knows 1C, all the same, deception is not an option. Therefore, I would not venture to continue without forming the reader’s understanding of the 1C platform and its capabilities used in vanessa-automation (hereinafter referred to as va or Vanessa ).

So, after installing the 1C platform, it must be run in the Enterprise mode or in the Configurator mode.

Configurations are being developed in the configurator, and in the enterprise , users work with these configurations: create, edit and save all such reference books and documents, thereby filling the database, and then generate reports and again: create, edit and save ... and so on in a loop. However, the usual scenario of using the platform by the developer, apparently, is not much different from the user:
launch the required configuration in the configurator mode, and then in a cycle → something is developed or modified → (re) is launched from the 1C configurator in enterprise mode and hands on what they have developed or modified.

The situation is saved by the functionality of the platform called Automated Testing , which makes it possible to record, play back, and test user actions. How this functionality changes the scenario of use by the platform developer is given by example, BUT first about External Treatments .

Application configuration objects (also known as "Metadata" , also known as "Configuration Objects" , she is Ella Katsnelbogen, she is Valentina Paniyad )
describe the subject area and the names of these objects speak for themselves.

"Documents" reflect business transactions, for example, the flow of goods. “Reference books” are needed in order to enter, for example, the name of the counterparty 1 time and then select it, and not enter it again each time. Data is stored in the "Registers" and virtual tables are built on them to perform complex calculations and generate "Reports" . So we got to the Processing , with their help the information of the database is processed (for example, the month is closed in accounting or various exchanges between information bases), but they are interesting for us to be able to upload to external processing .

The configurations supplied by 1C itself are on support (they cannot be changed so as not to lose the automatic update), and external processing allows you to perform various data manipulations without withdrawing from support, and, of course, to test!

With a certain degree of simplification, we can say that technically, external processing of 1C is a file with the epf extension opening which in the configurator, you can create many forms → place controls on the forms and program some functionality in the modules of these forms. Even external processing has a “common” module (aka “Object Module” ) and mockups, BUT, this is a completely different story, and we return to testing.

To use the Automated Testing functionality, you need to run two instances of the enterprise 1C, the first with the test manager key (/ TESTMANAGER), the second with the testing client key (/ TESTCLIENT) and establish a connection between the manager and the testing client. Thus, the scenario for a developer using a platform becomes:

From the configurator, we launch 1C in the enterprise mode with the key of the testing manager → we open va in the enterprise and use it to launch another instance
1C in enterprise mode with a client test key. Connection manager and client testing va sets automatically after running the test client. The test client can be either a thin client or a web client.

Total: 1C Company wrote its Selenium, which is built into the 1C: Enterprise platform. And this Selenium from 1C has advantages. For example, any control (it is control) on a form always has a unique name, which in 99.99% of cases is known in advance. Accordingly, there are no problems with locators, and in order to find a control element it is enough to write:

 = .(,,); 

Fix the material by example

It is necessary to develop a configuration to account for the sale of goods with printing invoices.

• Development
• Setup (performed 1 time)
• Testing or more visual screencast .

An attentive viewer might notice the design

  <>  

and you were not mistaken, yes - Vanessa uses her dialect gherkin, in which there are conditions and cycles. I think the idea of ​​adding conditions and cycles to gherkin was born like this:

Some members of the OpenSource community criticized this decision, but if you believe gitter , they agreed on the following - the "human readability" features do not harm this functionality, and everyone decides whether to use it or not.
About turbo gherkin planned separate article, stay tuned.

"BDD on 1C" and some history

va , as we see it now, was seen by its creators differently. It was decided to make the same cucumber + selenium on 1C only after having experienced the most obvious and low-cost options. At a certain point, it became clear that if you use cucumber and selenium, then it is these tools that will have to be refined to get the necessary testing functionality for 1C applied-business solutions. This alignment, within the framework of opensource and the realities of the world 1C, complicated and stretched the development of the project in time. As a result, it was decided to do only by means of the 1C: Enterprise platform.

On the example of the sale of goods, we saw how va works, now let's see how it is implemented.

Check steps

The video "Testing" shows va , into which a feature-file has already been downloaded (hereinafter feature ) and a tree of steps is formed. The "Run Scripts" button starts processing each step, i.e. call step verification procedure. About where this procedure is, I will explain with an example.

Let's say there is a feature with a script:

 :        ""  10     ""  300   ""   3000 

To implement the verification steps of this script, you need to get external processing that corresponds to the feature. In va this is done automatically, by the corresponding button.

As a result, the step_definitions directory will be created in the same directory as the feature, and an external processing with the same name as the feature will be created in it.

 ..\.feature ..\step_definitions\.epf 

The steps verification procedures will be located in the processing form module.

Further, when loading a feature, va will perform a search and a serial connection of external processing in order to find out the procedures for checking which steps in them (external processing) are implemented. The following procedure is responsible for this:

The sequence of search steps verification procedures is as follows:

 1.   ,  feature 2.   ,    ,    3.   ,       

In the event that a script is added / removed / changed in the feature, using the same button “Create and update processing templates” external processing can be repopulated with the corresponding feature.

By implementing step verification once, it can be used in other features ( reuse steps ). Actually, according to this, in the module of the external processing form, we see two procedures for checking the scenario from three steps.

Steps "out of the air" and WYCIWYG

It is a little about Functionality Automated testing of a platform 1C. Let me remind you, Automated Testing allows you to record, play back and check the reproduced user actions. In fact, these are all the same testing client and test manager , only on the client side a record of the user's actions is included.

As a result, we have an xml-file with a description of user actions:

 <?xml version="1.0" encoding="UTF-8"?> <uilog xmlns:d1p1="http://v8.1c.ru/8.3/uilog"> <ClientApplicationWindow isMain="true"> <CommandInterface> <CommandInterfaceGroup title="   "> <CommandInterfaceButton title=" "> <click/> </CommandInterfaceButton> </CommandInterfaceGroup> </CommandInterface> </ClientApplicationWindow> <ClientApplicationWindow caption=" "> <Form title=" "> <FormGroup name="" title=" "> <FormButton name="" title=""> <click/> </FormButton> </FormGroup> </Form> </ClientApplicationWindow> <ClientApplicationWindow caption="  ()"> <Form title="  ()"> <FormTable name="" title=""> <FormGroup name="" title=" "> <FormButton name="" title=""> <click/> </FormButton> </FormGroup> <FormField name="" title=""> <closeDropList/> <executeChoiceFromDropList presentation=""/> </FormField> </FormTable> </Form> </ClientApplicationWindow> <ClientApplicationWindow caption=""> <Form title=""> <FormTable name="" title=""> <gotoRow direction="down"> <Field title="" cellText="000000001"/> <Field title="" cellText=""/> </gotoRow> <choose/> </FormTable> </Form> </ClientApplicationWindow> <ClientApplicationWindow caption="  () *"> <Form title="  () *"> <FormTable name="" title=""> <endEditRow cancel="false"/> </FormTable> <FormGroup name="" title=" "> <FormButton name="" title="  "> <click/> </FormButton> </FormGroup> </Form> </ClientApplicationWindow> </uilog> 

It’s hard to say now whether the idea to create the functionality of the conversion of the user's actions log into the script steps lies on the surface, but it was the first to guess and implement this idea - Leonid Pautov ( pr-mex ). The amount of work done can be estimated by the content and size of the library , because in addition to translating the user action log into gherkin, it was necessary to implement the execution procedures and steps verification procedures.

Thus, in order to get the finished script "out of thin air", it is enough to enable the recording of user actions in the test manager.

In the testing client, reproduce user actions, such as functionality that needs to be improved or errors that need to be fixed. Well, complete the recording of user actions. Thus, the "WYCIWYG" approach to test development is implemented (What you click is what you get).

Steps, for example, checking the result of user actions in the script can be added from the library.

Detailing the steps and export scenarios

Unfortunately, in reality, the script consists of many steps, more than in the following screenshot.

There are at least two options to facilitate the perception of such scenarios.

First, using the tab "shift" the steps that need to be grouped and give them a mnemonic title.

Second, make the script concise and versatile and export. I think it’s impossible for me to describe this functionality better than Elena in the video "Using the tree tag and steps from the air" and "Passing parameters to the script . "

The video data ( 1 , 2 ) was also created from scripts on Gherkin and with the help of the "AutoVideoInstructions" engine converted to mp4 format in one click.

Yes, Vanessa can create videos about how Vanessa works)

AutoVideo

Automatic video instructions are the topic of a separate article ( here it is ), I can only tell a little background.

The moment of preparing the infobase, reproducing user actions and checking these actions, i.e. script execution
quite visual instruction, if you slow down the steps.

Putting users behind viewing the execution of the script (where does this police humor come from?) Is not an option, but the author didn’t stop at implementing the functionality of generating the html file with steps and corresponding screenshots. It was not stopped either by the fact that when reproducing user actions, the mouse cursor is not displayed and there is no possibility to select an arbitrary area on the form, so he wrote the corresponding utilities . Further, at the request of users, the voice acting ( Elena ) was added, which, with the main work on the formation of the video with subtitles and the original background music, resulted in a decent amount of work, but the auto-video instructions were worth it. At the moment, the auto-video instructions are significantly optimized, in terms of the synchronization of voice acting and actions on the video.

Some boring statistics

va supports:

• Versions of the 1C: Enterprise platform starting from 8.3.6 and higher (it is recommended to use the platform 8.3.10 and higher).
• Managed and as "normal" forms (the tested configuration may be in compatibility mode 8.2 or higher).
• Asynchronous call mode.

In order to work correctly on such a "zoo" , va had to learn how to test itself. The self test report looks like this:

Scripts for self testing are in the same repository .

Step library

The va delivery includes the Gherkin standard steps library, which allows you to solve everyday tasks of autodesiting, such as the operation and application interface (buttons, fields, tables, etc.), work with files, OS, etc. At the moment it is more than 400 steps.

Localization

The va interface is localized in 20 languages:

RU, am, az, bg, et, fr, ka, de, en, hu, it, lv, lt, mn, pl, ro, sl, es, sv, tr, vi.

Localization va can be divided into 3 components:

• Interface (using the regular mechanism of synonyms of the 1C: Enterprise platform).
• Messages to the user (instead of calling NSTR (), layouts with message translations are used).
• Translation of Gherkin steps from the standard library va . Those. instead of implementing the step "And I click on the 'Name Button" button in each language, the "mapping" is reused in the corresponding step of Gherkin, which is already implemented in Russian.
  In English, this step will be

 And I click 'ButtonName' button 

Therefore, English-speaking users can write scripts in English right now. All steps from the standard library are translated by man. The result may look something like this .

It is logical that in order to support such localization, we had to implement additional tools for working with layouts (a layout is something like an excel table) for inserting / deleting values, sorting rows, etc. directly in the source (xml files).

"TDD in 1C", testing procedures and functions (unit tests)

With va, you can check the "behavior" of procedures and functions. It is enough to write a similar script:

If readers have an interest, then this topic can be disclosed in more detail in future articles.

Delivery options

Initially, the project was delivered only as a set of epf files that could be collected from source on github , or download a ready release . Starting from version 1.2.009, va is also supplied as one epf file, which includes all libraries, plug-ins, localization packages, video assembly modules, etc. So to say - all in one.

This version of the framework is called vanessa-automation-single . It is well suited to those users who do not plan to refine va , but will only use. This delivery option is also well suited for inclusion in other configurations or extensions (since the FreeBSD project license allows it).

Top down and bottom up

Despite the fact that the tool was originally conceived for the implementation of the BDD methodology (i.e., when the scripts are written top-down, i.e. based on high-level customer requirements), the practice has shown that it is possible to write bottom-up scripts on it. Typical case - when there is already a ready configuration, and you just need to cover it with tests, without bothering with methodologies.

Morality

I hope the reader has developed (the keyword "formed") the idea of va as a serious testing tool. Looking at foreign analogues at the start, now va surpasses them, in my humble opinion. Expanding the functionality of working with gherkin, gave (promised, but not embodied to turbo gherkin) the opportunity to involve in the development process and analyst and developer and tester. Let me explain, the analyst writes a pass-through, high-level script → the developer details this script, including using export scripts, and besides the code he practically does not write anything (all the necessary UI steps are already in the library) → the tester adds scripts in order to check functionality and all this - in one feature-file , cheers comrades!

PS

At this point, let me complete this review article.
Support the project with a kind word / like / criticism (the project chat in Gitter is here ), it's always nice for the authors.

Thanks for attention!

Links

• Webinar
• Report at infostart event 2015
• Report on infostart event 2016 and answers to questions