November 7, 2011 at 12:12Regression testing of layout. Idea of automation
When we make up new features, or fix bugs in a small project, there is no problem to check if we have broken something that works. To do this, just click on it. But this does not always happen: our current project has about 200 unique pages and we are faced with the problem of automation of regression testing of layout. And if programmers have known everything for a long time, the methods are trivial, and the corresponding software is written, then we, front end developers, have to wrestle with it. But there are some thoughts.
In the context of this document, I will conditionally divide all layout errors into layout errors (associated with the position of the block in the document) and layout (such as the color of the text, background, etc.) Next, we will consider layout errors.
For layout, we use an approach like Object Oriented CSS . Thus, our page consists of blocks, blocks can be either simple, not containing other blocks, or composite, having simple blocks inside. We made our code as non-cascading as possible (with the exception of some inherited values, such as link color, text, and font), and it would seem that if we carefully do the ninth of the very block that undergoes changes, nothing should break. No matter how! Because:
In any case, all the changes that are caused by a change in one block should be known to us and controlled.
We need a universal method that allows us to find the maximum layout errors (and preferably not only layouts), regardless of the reasons for their origin.
She is simple. By and large, the only objective machine-accessible criterion for changing the layout of the document is to change the position of certain control points. Those. steps look like this:
Thus, we can use a similar method both in the development process and in bug fixing.
In my understanding in the physical sense, dots 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 program consists of client and server parts. The client converts comments into blocks, determines their coordinates and passes the values of the server part parameters. The server part compares the values of the points, adds new points to the database, processes the selection of the correct points by the developer.
I don’t know if, in principle, there are methods for automating testing layouts. Googling did not give any results, so I tried to come up with my own method. If you know the finished toolkit, please share it in the comments.
I tried to formalize 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 these are only the first sketches on the algorithm itself, I have only general considerations described above regarding the operation of the software . I do not claim to be exclusively faithful and effective in this approach. The first conclusions can be drawn only after the first results of the work.
And the most important thing,I encourage the general public to discuss in the comments everything that I described, to make comments and suggestions, as well as enthusiasts to help in the implementation of the software .
I will be grateful to everyone who puts a link to this post, places an announcement on their blogs, tweets, and generally helps in every way a wide discussion of this topic here or on my blog.
In the context of this document, I will conditionally divide all layout errors into layout errors (associated with the position of the block in the document) and layout (such as the color of the text, background, etc.) Next, we will consider layout errors.
Because of what the whole fuss
For layout, we use an approach like Object Oriented CSS . Thus, our page consists of blocks, blocks can be either simple, not containing other blocks, or composite, having simple blocks inside. We made our code as non-cascading as possible (with the exception of some inherited values, such as link color, text, and font), and it would seem that if we carefully do the ninth of the very block that undergoes changes, 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 this one, and to the pages into which this block is included. Therefore, in the general case, the presence of bugs is assumed.
- When changing blocks, again, in the general case, a violation of the alignment of blocks on the document grid is possible. As a result, “jumps” in levels of the same blocks may appear when switching pages.
- Mistakes can be caused by a human factor: sometimes a person is not alien, unfortunately, to concoct something quickly, no matter what a wonderful method we come up with.
- Errors can have absolutely any nature that we have not encountered before.
In any case, all the changes that are caused by a change in one block should be known to us and controlled.
We need a universal method that allows us to find the maximum layout errors (and preferably not only layouts), regardless of the reasons for their origin.
Idea of the algorithm
She is simple. By and large, the only objective machine-accessible criterion for changing the layout of the document is to change the position of certain control points. Those. steps look like this:
- In documents (source codes for simple blocks, compound blocks, pages on a dev server) we set some breakpoints
- The validator program determines the coordinates of these points relative to the coordinate system (for example, the upper left point of the browser workspace with horizontal and vertical axes) and writes their values to the database
- The validator program compares the previous coordinates of points with the current ones and gives a list of inconsistencies of the form "page address - point id - old coordinates - new coordinates"
- In manual mode, the developer scans these pages and marks the new values as correct (if this corresponds to the expected result of the changes made) or incorrect
Thus, we can use a similar method both in the development process and in bug fixing.
Validator and Milestones
In my understanding in the physical sense, dots 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:
- After the code of one block in the block sources
- In the block code in characteristic places (depends on each specific case)
- In the page code in characteristic places, and in the places of conditional guides of the document grid.
The validator program consists of client and server parts. The client converts comments into blocks, determines their coordinates and passes the values of the server part parameters. The server part compares the values of the points, adds new points to the database, processes the selection of the correct points by the developer.
Summary
I don’t know if, in principle, there are methods for automating testing layouts. Googling did not give any results, so I tried to come up with my own method. If you know the finished toolkit, please share it in the comments.
I tried to formalize 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 these are only the first sketches on the algorithm itself, I have only general considerations described above regarding the operation of the software . I do not claim to be exclusively faithful and effective in this approach. The first conclusions can be drawn only after the first results of the work.
And the most important thing,I encourage the general public to discuss in the comments everything that I described, to make comments and suggestions, as well as enthusiasts to help in the implementation of the software .
I will be grateful to everyone who puts a link to this post, places an announcement on their blogs, tweets, and generally helps in every way a wide discussion of this topic here or on my blog.