Regression Testing Layout. Idea of automation
When we typeset new features, or fix bugs in a small project, there is no problem to check whether we have broken something working. To do this, simply call him. But this is not always the case: our current project has about 200 unique pages and we are faced with the problem of automating regression testing of layout. And if everything has long been known to programmers, the methods are trivial, and the corresponding software is written, then we, the front end developers, have to rack our brains. But some thoughts are.
In the context of this document, I will conditionally separate all layout errors into layout errors (related to the position of the block in the document) and design (such as text color, background color, etc.). Next, we will consider layout errors.
In layout, we use an approach like Object Oriented CSS . Thus, our page consists of blocks, the blocks can be either simple, not containing other blocks, or compound, having simple blocks within themselves. We made our code as non-cascade as possible (with the exception of some inherited values, such as the color of the link, text and font), and it would seem that if we carefully create the devtest of the block that is being changed, nothing should break. No matter how! Because:
')
In any case, all the changes that make a change in one block must be known and controlled by us.
We need a universal method that allows us to find the maximum of layout errors (and preferably not only layouts), regardless of the reasons for their generation.
She is simple. By and large, the only objective machine-accessible criterion for changing the layout of a document is a change in the position of some control points. Those. steps look like this:
Thus, we can use a similar method both during development and bugfixing.
In my understanding in the physical sense, the points look like HTML comments of some template in the document code, for example
The points are supposed to be set according to the following logic:
The validator consists of client and server parts. The client converts comments into blocks, determines their coordinates, and passes the values of the server-side parameters. The server part compares the values of points, adds new points to the database, processes the selection of the correct points by the developer.
I don’t know if there are, in principle, methods to automate the testing of layout. Googling did not produce any results, so I tried to invent my own method. If you know the ready-made tools, please share them in the comments.
I tried to shape my thoughts on an absolutely universal testing system, which would be abstracted from the methods of implementing the layout, and therefore applicable to any project. While this is only the first sketches of the algorithm itself, I only have the general considerations described above for the operation of the software . I do not claim exceptional loyalty and effectiveness of this approach. The first conclusions can be made only after the first results of the work.
And, most importantly, I urge the masses to discuss in the comments everything I described, make comments and suggestions, as well as enthusiasts to help in the implementation of the software .
I will be grateful to anyone who links to this post, posts an announcement on their blogs, tweets and generally helps in every way to a wide discussion of this topic here or on my blog.
In the context of this document, I will conditionally separate all layout errors into layout errors (related to the position of the block in the document) and design (such as text color, background color, etc.). Next, we will consider layout errors.
Because of what all the fuss
In layout, we use an approach like Object Oriented CSS . Thus, our page consists of blocks, the blocks can be either simple, not containing other blocks, or compound, having simple blocks within themselves. We made our code as non-cascade as possible (with the exception of some inherited values, such as the color of the link, text and font), and it would seem that if we carefully create the devtest of the block that is being changed, nothing should break. No matter how! Because:
')
- As a result of manipulations with the block, the changes are pulled behind it to the composite block (if any) containing the given one, and to the pages in which this block is included. Therefore, in the general case, the presence of bugs is assumed.
- When changing blocks, again in the general case, the alignment of blocks on the document grid is possible. As a result, “jumps” of levels of the same blocks may appear when switching pages.
- Errors can be caused by the consequence of the human factor: unfortunately, sometimes it is not alien to a person to conceit something in a hurry, no matter how wonderful the method we have come up with.
- Errors can have absolutely any nature that we have not previously encountered.
In any case, all the changes that make a change in one block must be known and controlled by us.
We need a universal method that allows us to find the maximum of layout errors (and preferably not only layouts), regardless of the reasons for their generation.
The idea of the algorithm
She is simple. By and large, the only objective machine-accessible criterion for changing the layout of a document is a change in the position of some control points. Those. steps look like this:
- In the documents (source codes of simple blocks, compound blocks, pages on the dev server) we set some control points
- The program validator determines the coordinates of these points relative to the coordinate system (for example, the left upper point of the browser's working area with horizontal and vertical axes) and writes their values to the base
- The validator compares the previous coordinates of the points with the current ones and lists the inconsistencies of the form “page address — id points — old coordinates — new coordinates”
- In the manual mode, the developer views these pages and marks the new values as correct (in case this corresponds to the expected result of the changes made) or incorrect
Thus, we can use a similar method both during development and bugfixing.
Validator and control points
In my understanding in the physical sense, the points look like HTML comments of some template in the document code, for example
<!-- ###testing:id1### --> . Through the JS utility, embedded in each page and HTML source, they are replaced with an empty block with a zero height. Then the position of this block is calculated, also by JS.The points are supposed to be set according to the following logic:
- After the code of one block in the source code of blocks
- In the block code in the characteristic places (depends on each case)
- In the code of the page in the characteristic places, and in the places of the conditional guides of the grid of the document.
The validator consists of client and server parts. The client converts comments into blocks, determines their coordinates, and passes the values of the server-side parameters. The server part compares the values of points, adds new points to the database, processes the selection of the correct points by the developer.
Summary
I don’t know if there are, in principle, methods to automate the testing of layout. Googling did not produce any results, so I tried to invent my own method. If you know the ready-made tools, please share them in the comments.
I tried to shape my thoughts on an absolutely universal testing system, which would be abstracted from the methods of implementing the layout, and therefore applicable to any project. While this is only the first sketches of the algorithm itself, I only have the general considerations described above for the operation of the software . I do not claim exceptional loyalty and effectiveness of this approach. The first conclusions can be made only after the first results of the work.
And, most importantly, I urge the masses to discuss in the comments everything I described, make comments and suggestions, as well as enthusiasts to help in the implementation of the software .
I will be grateful to anyone who links to this post, posts an announcement on their blogs, tweets and generally helps in every way to a wide discussion of this topic here or on my blog.
Source: https://habr.com/ru/post/132031/
All Articles