Geekly Articles each Day
⬆️ ⬇️

Eleventh grader, or we test layout bugs





In today's web, unfairly little attention is paid to at least some automated UI testing. This is especially true of static layout. On the 2GIS Online project we tried to partially fill this gap. What useful practices we have acquired, and what good libraries we have learned, we will tell further.



Layout



Consider the story of one fictional button:





')

Square button with icon. It's simple. Dimensions can be hardcoded in pixels - what difference does it make?



Almost immediately, the button begins to evolve. Users rarely click a button. What to do? As an option - add an explanatory inscription. It remains only to slightly increase the width, so that the inscription is included:







But what about the inscription in Russian? Yes, and the original text may change. So hardcoding width is not possible, it is necessary to do an arbitrary:







There can be so much text that it cannot be read in one line. It is necessary to limit the maximum width and untie the height:







The button is still little used! You can make an auxiliary multi-line description. To do this, add a span-chick with the appropriate styles:







It seems that everything is already taken into account, and no one is able to break this layout. No one except the eleventh grader is a long word that does not fit the maximum width. Just do the transfer of letters:







Users began to complain about the obsessive large button, so it was decided to make a cross, closing the button without actually pressing. There are some styles for the cross, a bit of indentation for the title so that it does not fall under this cross - and everything is ready:







Do not forget that the main text may not be, we edit indents:







It seems now we have a multifunctional button for all occasions, with corrected bugs, right? Let's look at all the cases one more time, only now at the same time:







What do we see? Instead of a fully functional button, we see an abundance of regression bugs: the icon fell out of the button, the vertical alignment broke, an extra indent appeared for the cross ... In other words, we wanted the best, it turned out as always.



Now imagine that this is not about a button, but about a large, constantly developing project with a multi-million audience. Support turns into a hell, in which, unfortunately, many layout designers live.



There are many techniques and methodologies to help support the layout of complex projects. For example, BEM, which is widely known to all, which we also use. But the BEM methodology itself does not solve, but only localizes the regression bugs of the layout. How to get rid of them in principle? In fact, it is very simple (and for this you don’t need to learn the API of a dozen new js libraries!) - you need to create one test html page with all the button states. Let's be together, right now, create it, it will not take more than 10 seconds. Here you even markup: 



<!doctype html> <html> <head> <meta charset="utf-8" /> <!--    --> <link rel="stylesheet" href="style.css"> <title>Test page</title> </head> <body> <!--     --> </body> </html>


No js, ​​npm-dependencies, express-servers ... Just html-file, open in the browser.



For each evolutionary iteration, one or several new states must be entered (that is, variants of the html-code of the element under test, including content), but not old ones should be deleted. Viewing all the old states can be called semi-automatic regression.



We will deliberately not advise any means of automating this work, for two reasons: firstly, for most cases, every front-end can create such a page on its own; secondly, for complex cases, and pixel-perfect cases, we are writing our own solution, which we are not yet ready to announce.



Eleventh Grade



More than half of the layout bugs are associated with a very simple miscalculation: the front-end does not take into account that, generally speaking, any text can get into the text nodes of its layout. It can be multi-line, consist of long words, or it can be an empty string.



Take a couple of any of your layouts - I bet the Russian ruble is ready to argue that even an eleven- grader can break them. Insert a few eleven-graders in each field - the breakdown of the layout is guaranteed!



I suggest to open any popular site and execute the following code in the debugger 



 var a,w=document.createTreeWalker(document,NodeFilter.SHOW_TEXT);while(a=w.nextNode()){if(a.textContent.trim().length)a.textContent='    ,   ,  ,   '}


The first dozen sites that came to mind (excluding 2GIS Online, of course) were broken to such an extent that it became absolutely impossible to use them.



Of course, this does not mean that an eleventh-grader walks every day through all the text nodes of the Internet and breaks the layout (with the same success, the site can be protected from ebolavirus), but you should consider the following factors:



  1. If your project is in several languages, then another language may contain a longer phrase (Russian is longer than English, Spanish is longer than Russian, etc.)
  2. The user may not have a main font, and the fallback will be larger
  3. The user can have a custom zoom or another font rendering engine.
  4. The text can be changed during the support process, including by content managers who will not be sure to check the layout.
  5. The wrong text can fly to the field simply because of a bug in the js code
  6. A bug in the layout of another block can shrink your block
  7. Someone read this article and execute the given code in the debugger :)


We sincerely believe that in any of these cases the entire text should be visible to the user, and it should be readable. He can uncritically change the size of the block, go to fade or break with ellipsis; but it should not turn into the attacking neighboring monster nodes, burning out the user's eyes; that is, it should at least not fit into another text.



Automation



Everything about what we wrote above cannot be called automatic testing, because it requires a human eye. If you do not want to strain your eyes at all, the tests that we call dom tests will help you.



A Dom test is a js code running in a browser that checks something in the isolated part of the application, or in the entire application. Anything can be checked: from the presence of a class and an attribute in html, to the arguments with which a function was called, including an asynchronous one.



Here you will be helped by such wonderful libraries as:



mocha . A framework for testing. Allows you to create tests and test groups, including asynchronous; execute some code before a test or a group of tests, and after it.



chai . Library for asserts. In principle, you can use the native assert node.js, but the “tea” has buns, for example, a beautiful diff deepEqual.



sinon . A library that allows you to do two important things:





By combining all this, you can write tests both on the entire application and on its isolated parts. In these tests, you can do literally everything: fill out the form and click on the buttons; change dom-tree; make ajax requests ... In fact, inside such tests you are inside the browser debugging console, and in your hands are any js-libraries for testing that you like.



The advantage of such tests is that they are performed in the browser, which means that they can be run in any browser with zero resources for adaptation (which cannot be said about the selenium drivers, especially in combination, say, with ie8 android 4.0). In addition, such tests can be run in fully automatic mode on phantomJS, for example on git-push hooks.



Just in case, it should be noted that dom tests are not an alternative to regression testing of typesetting; this is just another code protection approach, with its own specifics and scope.



findings



Get a html-page for the layout regression, put an eleventh- grader in it, and your layout will be 10 times better. Protect your code with js-tests, and you will be able to refuse the services of testers (who will have to retrain in automators and help you write tests). On the 2GIS Online project, 90% of the tasks get into combat without manual testing, and this was largely made possible by the above testing approaches.



Do not wait for the eleventh grader to come to you herself!



More information can be gleaned from my performance on Web Standards Days.

Source: https://habr.com/ru/post/246831/

More articles:



All Articles