Just as always – hm, the second time for me – SoCraTes 2015
was just great and the workshop I joined on Sunday just emphasized it: Getting into touch with Selenide
, hosted by Alexei Vinogradov.
Selenide – jQuery for Java
Knowing Selenium for long now getting off with Selenide
was a piece of cake – and knowing Selenium it just was great to feel how easy it is to use Selenide. I would really recommend it, especially if you are known to jQuery
and want to have a similar feeling to access elements in Selenide. But Selenide provides far more (and I suggest even far more than I learned on that session).
Accessing Ext JS through Selenide
Not knowing Ext JS
by heart – but at least having experience how to access Ext JS (the old version 3) from within automatic UI-Tests – I was curious how I would be able to access the components using Selenide.
Ext JS knows much better than any DOM-path-navigation how to locate components.
Mirroring the component class hierarchy in Java helps us to also spread the knowledge how to access state of the components through the hierarchy – and possibly override it, if a specialized component requires some other approach for example to determine if it is visible.
Having the wrappers it’s not a piece of cake to update Ext JS versions (at least when you try from Ext JS 3 to Ext JS 5+) – but it is feasible. You just have to update some central wrappers and all UI-tests are fine again without even touching the tests themselves.
Actually it is the same for fixing issues in the UI-tests: For example the knowledge how to do a robust drag and drop is hidden deep within the wrappers – and it gets enriched by workarounds each time we learn how to make it even more robust. Again it’s just one small change and with a finger snap all drag and drop tests behave much better.
Adapt for Ext JS 5 and Selenide
I took the challenge to adapt this concept during the one-day workshop for Ext JS 5 using Selenide. What I learned from this proof-of-concept:
Ext JS now has a ComponentQuery
which eases accessing components a lot. It feels similar to the jQuery syntax.
Change SUT and Tests:
Just as always: It would be good to have control over the software under test
(SUT) as well as over the tests. Otherwise – as you can see in the PoC – you will for example miss clear IDs (or item IDs) to access elements. As I tested against the examples hosted by Sencha I had no control over the SUT.
Selenide vs. StaleElementReferenceException:
If you write UI-tests with Selenium you will for sure know it: the StaleElementReferenceException
. For AJAX applications it is quite normal that the DOM changes and if it changes it is most likely that some elements you accessed in Selenium WebDriver before are not available anymore. Selenium documentation recommends to just update the reference. And here some of Selenide’s magic happens: It will do the trick for you: it will automatically refresh the reference transparently for the test. By the way: While doing the PoC I ran into a deadlock not knowing this behavior when I used an implementation which goes through Selenide → Selenium → Selenide (used Selenide in a By-instance). I did not analyze this in depth but the observation was that the UI test was just stuck in locating the element.
Local Browser Start:
What is a pain in Selenium WebDriver is to start a browser locally. Especially if you want to support several browsers. Selenide provides this out of the box – also for connecting to the Selenium WebDriver Grid. See FAQ
To give it a try just checkout the PoC from GitHub
and either start the build via gradle ( gradlew test
) or just right from within your IDE.
The proof-of-concept was up and running within about 2 hours. It took less than a day (with helpful hints provided by Alexei, thanks for that!) to get the whole PoC to a state where you could get an idea how we might continue from here.
I definitely recommend to give Selenide a try to anyone testing “normal”
web pages as a syntax similar to to jQuery just makes it a piece of cake to access the same elements from within your UI tests. But also for rich web applications I recommend to give Selenide a try because of many aspects – not only because the assertion approach using (possibly) custom conditions in the should() statements not mentioned (despite here) in this blog-post promises to provide additional flexibility for checking for example required component states in Ext JS.
There is so much more to say about SoCraTes – not only that I will participate again next year and that I have to thank the organizers a lot! But I think this video shows best that there is some magic going on in Hotel-Park-Soltau
(the great location where SoCraTes took place for the second time):