Testing Ext.Js project on Selenium
There are three things you can do endlessly:
1. Watch the fire burn
2. Watch the water run
3. And watch someone work
In our case, watch how our over 9000 tests run. Especially beautiful look Selenium tests. It looks like a rabid jerboa with a perpetual motion engine inside the villages to test the system.
I do not know about you, but it delays me:
')
The rest of the article I will tell a little success-story about how we organized our testing on Selenium
This was our second approach to the projectile. For the first time, back in 2009, everything fell:
• Web driver only worked with IE.
• Sometimes it hangs when opening a browser
• Sometimes could not close the browser
• And most importantly: the built-in recording of tests through a browser extension (the so-called “click”) did bad tests for the Ext.Js shell.
Our project is written using Ext.Net - Ext.Js shell for .NET. And Ext.Js was obviously too complicated for Selenium. It generated random identifiers of elements for the client, and additionally random identifiers of objects were also generated by ourselves (which is necessary for parallelism and high loads of our platform).
It seems that the test can be easily clicked with the mouse, but the lifetime of this test was a matter of days. Worse, when the test fell, it was often more difficult to understand the cause of the fall than to simply re-call it again (which was done a couple of times).
And the tests were slow! Submit a script:
1. We drive the search string into the data table
2. The server returns the response - an empty grid (which can sometimes be correct)
3. And after it sends an error message if it occurred.
Ext.Js with its asynchronous requests for any click is designed so that for many calls we need to wait for an error message of 10 seconds and if we did not receive it, we thought that the search worked fine.
10 seconds here, 10 there and as a result, the test itself consists of waiting for 90% of the time.
And that is not all. Have you tried to understand the reasons for the fall of the crooked dough from the Selenium log? So, in order not to rerun the test, but to look at the log and understand the essence of the problem. I - did not work.
After a couple of months, it became clear that such testing takes more time than it does good, and we killed Selenium tests.
The project, meanwhile, was growing, the number of functions was measured in thousands, and now, a year ago, the heroic selmaril returned to this problem with an updated Selenium and an updated understanding of how to test Ext.Js
His solution was to write an API.
We decided to refuse to write tests with the mouse, but to come to the opportunity to write NUnit (!) Tests with a short notation in the form:
1. Filter users by creation date = today.
2. Sort by name
3. Open the first entry
4. Change password.
5. Save.
6. Click OK if the "Are you sure" window pops up.
To do this, you needed an API over Selenium and NUnit, which itself would consist of very simple elements, but allowing you to operate not with the mouse and the DOM model, but with the objects of the Ext.Js. interface.
A month of hard work, and the first version of the API appeared.
An important problem was also solved - quick understanding of the error from the TeamCity log. Api generates such a report for each test.
The bottom line: now we have covered about 80% of the behavior of the system interface. I share the experience of our experience. To test Ext.Js on Selenium, you need to write your own wrapper for testing to solve the following problems:
1. Conciseness and clarity of the test
2. The stability of the test to change the system
3. Test speed
4. It is easy to understand the causes of breakage of the dough.
Tests created by clicking from the browser interface will probably not work for you.
PS
If you have an Ext.Js project and you decide to cover it with Selenium with tests - contact us for tips, we will try to help.
1. Watch the fire burn
2. Watch the water run
3. And watch someone work
In our case, watch how our over 9000 tests run. Especially beautiful look Selenium tests. It looks like a rabid jerboa with a perpetual motion engine inside the villages to test the system.
I do not know about you, but it delays me:
')
The rest of the article I will tell a little success-story about how we organized our testing on Selenium
This was our second approach to the projectile. For the first time, back in 2009, everything fell:
• Web driver only worked with IE.
• Sometimes it hangs when opening a browser
• Sometimes could not close the browser
• And most importantly: the built-in recording of tests through a browser extension (the so-called “click”) did bad tests for the Ext.Js shell.
Our project is written using Ext.Net - Ext.Js shell for .NET. And Ext.Js was obviously too complicated for Selenium. It generated random identifiers of elements for the client, and additionally random identifiers of objects were also generated by ourselves (which is necessary for parallelism and high loads of our platform).
It seems that the test can be easily clicked with the mouse, but the lifetime of this test was a matter of days. Worse, when the test fell, it was often more difficult to understand the cause of the fall than to simply re-call it again (which was done a couple of times).
And the tests were slow! Submit a script:
1. We drive the search string into the data table
2. The server returns the response - an empty grid (which can sometimes be correct)
3. And after it sends an error message if it occurred.
Ext.Js with its asynchronous requests for any click is designed so that for many calls we need to wait for an error message of 10 seconds and if we did not receive it, we thought that the search worked fine.
10 seconds here, 10 there and as a result, the test itself consists of waiting for 90% of the time.
And that is not all. Have you tried to understand the reasons for the fall of the crooked dough from the Selenium log? So, in order not to rerun the test, but to look at the log and understand the essence of the problem. I - did not work.
After a couple of months, it became clear that such testing takes more time than it does good, and we killed Selenium tests.
The project, meanwhile, was growing, the number of functions was measured in thousands, and now, a year ago, the heroic selmaril returned to this problem with an updated Selenium and an updated understanding of how to test Ext.Js
His solution was to write an API.
We decided to refuse to write tests with the mouse, but to come to the opportunity to write NUnit (!) Tests with a short notation in the form:
1. Filter users by creation date = today.
2. Sort by name
3. Open the first entry
4. Change password.
5. Save.
6. Click OK if the "Are you sure" window pops up.
To do this, you needed an API over Selenium and NUnit, which itself would consist of very simple elements, but allowing you to operate not with the mouse and the DOM model, but with the objects of the Ext.Js. interface.
A month of hard work, and the first version of the API appeared.
Here is a sample of the test:
/// <summary> /// DocumentOperationGridOperationTest /// </summary> [Test] public void DocumentOperationGridOperationTest() { var baseDocName = typeof(BaseInDocument).ModelName(); var implDocName = typeof(BaseInDocumentImpl).ModelName(); using (var grid = Env.Navigation.OpenList(implDocName)) { var operationCaption = "_"; grid.Toolbar.Click(operationCaption); var docForm = Env.TabPanel.GetForm(implDocName); docForm.Toolbar.Click("", " {0}".FormatWith(operationCaption)); docForm.Close(); } using (var grid = Env.Navigation.OpenList(baseDocName)) { var operationCaption = "_"; grid.Data.First().Select(); grid.Toolbar.Click("", operationCaption); grid.Toolbar.Click(""); var docForm = Env.TabPanel.GetForm(implDocName); var fieldValue = docForm.GetField<TextField>("SomeNewField"); Assert.False(string.IsNullOrEmpty(fieldValue.GetValue()), " , "); grid.DeleteFirstRow(); docForm.Close(); } } But what does the API implementation look like?
/// <summary> /// /// </summary> /// <param name="fieldName"> , </param> /// <param name="buttonCaption"> , ( )</param> /// <returns> </returns> public IToolbarElement GetContextMenuItem(string fieldName, string[] buttonCaption) { var buttonsFullPath = Oreodor.Utils.EnumerableExtensions.ToString(buttonCaption, "->"); Env.AddHistory(" Id - SysName = {0} - {1}, {2}, '{3}'".FormatWith( Id, this.Data.ContainsKey("SysName") ? this.Data["SysName"] : string.Empty, fieldName, buttonsFullPath)); IToolbarElement menuItem = null; if (buttonCaption.Length > 0) { var menuItems = new List<IToolbarElement>(); if (IsContextMenuVisible(fieldName)) { menuItems.AddRange(GetCurrentContextMenu()); } else { menuItems.AddRange(ShowContextMenu(fieldName)); } menuItem = Toolbar.CheckItem(menuItems, buttonCaption[0]); if (buttonCaption.Length > 1) { for (var i = 1; i < buttonCaption.Length; i++) { var menuCaption = buttonCaption[i - 1]; var itemCaption = buttonCaption[i]; var menu = menuItem.Menu.ToList(); Assert.That(menu.Count() != 0, " '{0}' , .. '{1}'.".FormatWith(menuCaption, itemCaption)); var candidateToolbarItem = Toolbar.CheckItem(menu, itemCaption); Assert.That(candidateToolbarItem != null, " '{0}' '{1}'. : {2}".FormatWith(itemCaption, menuCaption, menu.Aggregate(", ", (aggregated, item) => aggregated + "'" + item.Text + "'"))); menuItem = candidateToolbarItem; } } } return menuItem; } An important problem was also solved - quick understanding of the error from the TeamCity log. Api generates such a report for each test.
The bottom line: now we have covered about 80% of the behavior of the system interface. I share the experience of our experience. To test Ext.Js on Selenium, you need to write your own wrapper for testing to solve the following problems:
1. Conciseness and clarity of the test
2. The stability of the test to change the system
3. Test speed
4. It is easy to understand the causes of breakage of the dough.
Tests created by clicking from the browser interface will probably not work for you.
PS
If you have an Ext.Js project and you decide to cover it with Selenium with tests - contact us for tips, we will try to help.
Source: https://habr.com/ru/post/181660/
All Articles