Scenario testing to help 1C programmer
The topic of scenario testing has long been revealed, and the awareness of the need to use TDD and BDD to some extent exists in almost every company. The exception was not our small group of 1C developers. However, from the moment of understanding the need, to the actual use of technology, time passes, and in this way immature minds, such as the author of this article, begin to think about the effectiveness of this whole undertaking. If you are interested in how a group of intelligent guys have implemented something similar to scenario testing in their work - welcome.
There are very powerful and developed user interface testing tools on the market. There are special scripting languages, a lot of documentation and methodologies. In other words, “Is there a problem? There is a solution!".
On the other hand, the energy expended in solving the problem must somehow correspond with the energy produced by the team as a whole. And in practice, if large companies can allow individual QA-specialist (s) and testers to deploy the process to the full extent, small offices are not always able to, part of the functions have to be imposed on themselves, and the philosophy of the process is slightly bent. .
So, given: a geographically distributed development team for 1C for up to 10 people, on average, for up to 5 active projects, mainly the development of custom solutions without using typical 1C products.
')
Task: most effectively implement development testing processes, including testing the operation of the interface and business logic. Efficiency is the balance when the time spent on testing still makes sense in terms of the final result. I admit that this line is very subjective, and perhaps fully justifies the expression "an attempt to compare warm with soft." What goals scenario testing serves as such, I think the reader knows even better than the author.
After researching a number of instrumental systems of Western vendors, as well as screenwriting testing from 1C version 3.0, and xUnitFor1C, it seemed that we hadn’t grown up mentally to implement these technologies. Time passed, but we still can not grow. At the same time, the inside required everything and required at least some kind of solution.
Having picked up old records, the list of requirements to the potential software product was once again compiled:
Of course, the list is far from complete, and to some extent present in other software products. It may seem youthful maximalism, but only when all these conditions are met in one product, we saw the possible implementation of scenario testing in our situation. Colleagues may not agree with me, but I am of the opinion that one of the key problems with the quality and quantity of tests as such is how quickly and conveniently these tests can be done in a continuous application development mode.
Probably another six months passed, and finally I decided to start in the sluggishly optional mode the development of the next bike tester (hereinafter - the tester), and this is what came of it.
As a result, a 1C application was born, in which scenario tests for 1C solutions are written and executed. Daily use is something like this: the tester is open for the programmer on the second monitor the whole working day. In the project accounting database, the manager indicates a mandatory set of tests with which the project should be covered.
There are also a number of standard, mandatory tests that must be performed by the programmer for each task. For example, if a document is entered on a base, there must be an input test on the base. In other words, the programmer knows which tests should be created.
In practice, writing tests in half of the cases occurs during the development process (very convenient for automating the routine, when it is required to repeat the same actions at each restart of the application). In the other half - after. As a sophisticated reader probably noticed, it is difficult to call such a situation a classic BDD.
Suppose there is a project “Develop a document Assembling a kit”. This document requires a list form with a filter by warehouse. The general concept of the work of the lists in this decision is as follows: if the filter is installed, besides selecting documents by filter value, the selection value is required to serve as the default value when entering a new document from this form. Thus, if a warehouse is installed, it must be automatically installed when a new document is entered.
Only at first glance it seems that the test is not needed for such a scenario, however, given the variety of options for entering documents, the Warehouse field can take on different values. After all, the document can be copied, or the user has a different company specified in the default settings, and the warehouse selected in the filter is not its organizational unit. Anyway, this is how the test will look like (we have foreigners in the team, therefore the tester itself is written in English, and the application solution itself is intended for the work of American clients):
Above - a developed application, from below - a tester, in the thin client mode of operation, a database of tests in the cloud. The code that you see is written in 1C. The script code interacts with the launched client application through the wrappers of the methods of the tested application 1C, for example, this is how the Choose (...) method looks like;
I tried to implement almost all interface operations in the tester, but even if you need something specific, you can always get the object of the field under test and perform any methods implemented in the model of the application under test on it.
Move on to more interesting scenarios.
In order to develop a script for creating and carrying out an Assembling document, as in the previous example, we need to have a lot of additional data: the necessary list of reference books, the remnants of materials in the warehouse, which at least means that there is some kind of arrival at the warehouse. As I said earlier, we decided for ourselves that the tests should be performed under conditions when the reference database does not exist, there is only the initial image of the application, where there is at least one user with administrative rights, full classifiers, and default values ​​for comfortable initial work user
However, to write every time a complete script that will create all the necessary “along the way” data will be inefficient. I would like to develop a parameterized test that not only knows how to do something, but also takes parameters. For example, in order to create a receipt in the database, there must be a test that will create it. And nothing prevents us from making this test parametrized, and transferring all the necessary data to it, for example, what date to make the parish, to which warehouse and what materials / services to come. In turn, the test for building a parish will use tests for the creation of a warehouse, materials that will be expected in the parameters for the type of packaging, type, conversion factors, and so on.
Since our application is cloudy and the test base is one, each programmer, developing a test, can parameterize it in the process of writing a test to something, opening it up for wide use by other programmers.
Here is an example of how the Assembling creation test prepares for admission:
(prices, sums and numbers are set as strings to avoid the problems of false testing of the test if it is run in a different locale, where the triad separator and the fractional part, for example, may differ)
During the execution of this test, a number of other tests will be performed, which will create everything necessary for being able to test Assembling as such. This is approximately what will be the result in the database:
Besides the fact that all the buttons “clicked” and the fields “went out”, the test event would have left a deep scar on the heart if I hadn’t tested the results of the mechanisms of the document, and did not appreciate the current accounting situation in the database.
I confess for a long time puzzled how it is better to implement it so that without a reference base, and so easily and simply. Nothing better, I did not think of how easy it is to perform the verification of document movements in conjunction with the testing of statements.
Here is an example of a report on document movements in the application under test:
Here is how the tester will check these movements:
Red areas are relevant for verification. In addition to the areas in the tester, you can set the validation of fields on the template.
Often there is the task of checking the same type of objects. For example, in half of the cases, forms of documents have a tabular part, and software errors are often made when copying lines, deleting the first line, or entering and refusing to enter the first / subsequent lines. For this purpose, it is possible to develop a test method that does not have a stand-alone script, but is used only for a place call. This is very convenient, because over time, such tests can be increased by adding other elements of testing there, which entails the automatic expansion of the application coverage through the widespread use of such tests.
There are at least three types of errors that I would like to control. The first kind is coding errors, such as division by zero, reference to a nonexistent property or method. The second type of error is an error in logic, for example, when you press a button, the form should close, but this does not happen, or when you check the box, a part of the form should become inaccessible or invisible. And the third type of errors, business logic errors, for example, when writing off material from a warehouse, could not determine its presence against the base. All three types of errors can be worked out in the tester. When triggered, the tester registers an exception, writes it to the log and can show a call stack, for example, like this:
A number of methods for error handling business logic were also implemented. For example, your test intentionally wants to write off more material and you want to check whether the message will be formed correctly and whether it will be formed at all.
Here is an example of the implementation of such a test in one of the tests:
The tester can read the visual objects of the application under test. This is convenient, and sometimes it is just necessary to write a script, especially for multilingual solutions, where the names of the buttons depend on the user's language, and you have to use an internal identifier to work out the interface (unless of course there is a task to check the syntax of the labels on the buttons). Here is an example of how the tester presents the read data:
In general, it turned out a small bike to help the 1C programmer. As the positive qualities of the program, the following can be noted:
And of course, much has not yet been implemented:
The tester is open and free, preferably starting from 8.3.8, but on 8.3.7 it will also work if you turn on the compatibility mode. Inside there is a small help (swelled from an Internet), there are wrappers for methods in Russian, dt-shnik can be downloaded from here . There are a couple of examples for accounting office building 3.0.
Good luck to you friends and thanks for your attention!
Prehistory
There are very powerful and developed user interface testing tools on the market. There are special scripting languages, a lot of documentation and methodologies. In other words, “Is there a problem? There is a solution!".
On the other hand, the energy expended in solving the problem must somehow correspond with the energy produced by the team as a whole. And in practice, if large companies can allow individual QA-specialist (s) and testers to deploy the process to the full extent, small offices are not always able to, part of the functions have to be imposed on themselves, and the philosophy of the process is slightly bent. .
So, given: a geographically distributed development team for 1C for up to 10 people, on average, for up to 5 active projects, mainly the development of custom solutions without using typical 1C products.
')
Task: most effectively implement development testing processes, including testing the operation of the interface and business logic. Efficiency is the balance when the time spent on testing still makes sense in terms of the final result. I admit that this line is very subjective, and perhaps fully justifies the expression "an attempt to compare warm with soft." What goals scenario testing serves as such, I think the reader knows even better than the author.
After researching a number of instrumental systems of Western vendors, as well as screenwriting testing from 1C version 3.0, and xUnitFor1C, it seemed that we hadn’t grown up mentally to implement these technologies. Time passed, but we still can not grow. At the same time, the inside required everything and required at least some kind of solution.
Having picked up old records, the list of requirements to the potential software product was once again compiled:
- Solution must be cloudy.
- The base of tests for all developments should be unified.
- Must have access control to applications (each programmer has his own development pool)
- Test development and execution should be in the same IDE
- Scripts must be programmed, not recorded by user actions.
- It is desirable that the test programming language was similar to 1C
- Running tests should be done on a single button, without preliminary manipulations, compilations, builds, uploads, downloads and other
- In the process of writing a test, it should be possible to analyze the structure of windows and details of the application under test in terms of the 1C managed interface model, and this should be in the program where the test itself is being developed. It should be possible to get the properties of the fields of the application under test, while passing through the control tree in the testing database - the application under test should respond and show where this control is.
- A reference database should not be used to test business logic.
- To work out the test, there should not be a specially prepared base, all tests should be able to work and create everything you need.
Of course, the list is far from complete, and to some extent present in other software products. It may seem youthful maximalism, but only when all these conditions are met in one product, we saw the possible implementation of scenario testing in our situation. Colleagues may not agree with me, but I am of the opinion that one of the key problems with the quality and quantity of tests as such is how quickly and conveniently these tests can be done in a continuous application development mode.
Probably another six months passed, and finally I decided to start in the sluggishly optional mode the development of the next bike tester (hereinafter - the tester), and this is what came of it.
What it looks like
As a result, a 1C application was born, in which scenario tests for 1C solutions are written and executed. Daily use is something like this: the tester is open for the programmer on the second monitor the whole working day. In the project accounting database, the manager indicates a mandatory set of tests with which the project should be covered.
There are also a number of standard, mandatory tests that must be performed by the programmer for each task. For example, if a document is entered on a base, there must be an input test on the base. In other words, the programmer knows which tests should be created.
When tests are written
In practice, writing tests in half of the cases occurs during the development process (very convenient for automating the routine, when it is required to repeat the same actions at each restart of the application). In the other half - after. As a sophisticated reader probably noticed, it is difficult to call such a situation a classic BDD.
Sample test
Suppose there is a project “Develop a document Assembling a kit”. This document requires a list form with a filter by warehouse. The general concept of the work of the lists in this decision is as follows: if the filter is installed, besides selecting documents by filter value, the selection value is required to serve as the default value when entering a new document from this form. Thus, if a warehouse is installed, it must be automatically installed when a new document is entered.
Only at first glance it seems that the test is not needed for such a scenario, however, given the variety of options for entering documents, the Warehouse field can take on different values. After all, the document can be copied, or the user has a different company specified in the default settings, and the warehouse selected in the filter is not its organizational unit. Anyway, this is how the test will look like (we have foreigners in the team, therefore the tester itself is written in English, and the application solution itself is intended for the work of American clients):
Above - a developed application, from below - a tester, in the thin client mode of operation, a database of tests in the cloud. The code that you see is written in 1C. The script code interacts with the launched client application through the wrappers of the methods of the tested application 1C, for example, this is how the Choose (...) method looks like;
I tried to implement almost all interface operations in the tester, but even if you need something specific, you can always get the object of the field under test and perform any methods implemented in the model of the application under test on it.
Move on to more interesting scenarios.
Interrelation of tests
In order to develop a script for creating and carrying out an Assembling document, as in the previous example, we need to have a lot of additional data: the necessary list of reference books, the remnants of materials in the warehouse, which at least means that there is some kind of arrival at the warehouse. As I said earlier, we decided for ourselves that the tests should be performed under conditions when the reference database does not exist, there is only the initial image of the application, where there is at least one user with administrative rights, full classifiers, and default values ​​for comfortable initial work user
However, to write every time a complete script that will create all the necessary “along the way” data will be inefficient. I would like to develop a parameterized test that not only knows how to do something, but also takes parameters. For example, in order to create a receipt in the database, there must be a test that will create it. And nothing prevents us from making this test parametrized, and transferring all the necessary data to it, for example, what date to make the parish, to which warehouse and what materials / services to come. In turn, the test for building a parish will use tests for the creation of a warehouse, materials that will be expected in the parameters for the type of packaging, type, conversion factors, and so on.
Since our application is cloudy and the test base is one, each programmer, developing a test, can parameterize it in the process of writing a test to something, opening it up for wide use by other programmers.
Here is an example of how the Assembling creation test prepares for admission:
(prices, sums and numbers are set as strings to avoid the problems of false testing of the test if it is run in a different locale, where the triad separator and the fractional part, for example, may differ)
During the execution of this test, a number of other tests will be performed, which will create everything necessary for being able to test Assembling as such. This is approximately what will be the result in the database:
Testing business logic
Besides the fact that all the buttons “clicked” and the fields “went out”, the test event would have left a deep scar on the heart if I hadn’t tested the results of the mechanisms of the document, and did not appreciate the current accounting situation in the database.
I confess for a long time puzzled how it is better to implement it so that without a reference base, and so easily and simply. Nothing better, I did not think of how easy it is to perform the verification of document movements in conjunction with the testing of statements.
Here is an example of a report on document movements in the application under test:
Here is how the tester will check these movements:
Red areas are relevant for verification. In addition to the areas in the tester, you can set the validation of fields on the template.
Typical checks
Often there is the task of checking the same type of objects. For example, in half of the cases, forms of documents have a tabular part, and software errors are often made when copying lines, deleting the first line, or entering and refusing to enter the first / subsequent lines. For this purpose, it is possible to develop a test method that does not have a stand-alone script, but is used only for a place call. This is very convenient, because over time, such tests can be increased by adding other elements of testing there, which entails the automatic expansion of the application coverage through the widespread use of such tests.
Error control
There are at least three types of errors that I would like to control. The first kind is coding errors, such as division by zero, reference to a nonexistent property or method. The second type of error is an error in logic, for example, when you press a button, the form should close, but this does not happen, or when you check the box, a part of the form should become inaccessible or invisible. And the third type of errors, business logic errors, for example, when writing off material from a warehouse, could not determine its presence against the base. All three types of errors can be worked out in the tester. When triggered, the tester registers an exception, writes it to the log and can show a call stack, for example, like this:
A number of methods for error handling business logic were also implemented. For example, your test intentionally wants to write off more material and you want to check whether the message will be formed correctly and whether it will be formed at all.
Here is an example of the implementation of such a test in one of the tests:
Element tree analysis
The tester can read the visual objects of the application under test. This is convenient, and sometimes it is just necessary to write a script, especially for multilingual solutions, where the names of the buttons depend on the user's language, and you have to use an internal identifier to work out the interface (unless of course there is a task to check the syntax of the labels on the buttons). Here is an example of how the tester presents the read data:
Conclusion
In general, it turned out a small bike to help the 1C programmer. As the positive qualities of the program, the following can be noted:
- Tester is easy to install and configure.
- It is initially multi-user (users are also created in the tester, in the administration subsystem)
- Does not require special knowledge to write tests
- Allows you to implement complex business logic scripts
- Allows in one database to keep thousands of tests for different projects and "reuse" them. For example, you can create a test for a search for a document listed by number for all projects. Or if the client base is implemented on the basis of a typical solution for which there are already tests, you can check the client base by calling all the parent tests, plus tests specifically designed for the client
And of course, much has not yet been implemented:
- No test run schedule
- There is no advanced analysis system, graphs and reports on test results.
- No automatic mailings and notifications about what was broken, who broke and why
- No connection to repositories, and test versioning
The tester is open and free, preferably starting from 8.3.8, but on 8.3.7 it will also work if you turn on the compatibility mode. Inside there is a small help (swelled from an Internet), there are wrappers for methods in Russian, dt-shnik can be downloaded from here . There are a couple of examples for accounting office building 3.0.
Good luck to you friends and thanks for your attention!
Source: https://habr.com/ru/post/307808/
All Articles