Selenide - Concise UI Tests in Java

Andrei Solntsev, @asolntsev, Codeborne, http://codeborne.com/

Selenide is an open source software testing tool for writing concise, expressive and stable UI tests in Java. Selenide resolves all the typical problems with testing of modern web applications like Ajax and timeouts in a simple and elegant way. Selenide is extremely simple to start with: you don't need to read hundreds-pages-long tutorials. Just open IDE and start writing. Learning curve is close to zero. With Selenide you don't waste time on googling "how to make Selenium do that" - you can concentrate on business logic.

Selenide = a better Selenium

Web Site: http://selenide.org/
Version tested: Selenide 2.6.1
Language: Java and other JVM languages: Scala, Groovy etc.
System requirements: Windows, Linux, OS X, Android etc. - wherever Selenium works
License & Pricing: Open-source, free, LGPL 3.0
Support: Selenide is created and supported by Codeborne company.

Introduction to Selenide

Ideally, we should write several types of tests for our applications: unit tests, functional tests, integration tests etc. For web applications we typically write scripts that open the application in web browser (either real or headless) and start clicking buttons. We call them user interface (UI) tests.

The most common tool for UI tests in Java today is Selenium WebDriver. Though it's a great tool, it still can be improved. We were missing expressibility and stability in our tests, as well as we were tired of timeouts and lack of Ajax support. That's why we created Selenide - a dedicated library for UI Tests on top of Selenium.

To feel the taste of Selenide, take a look at the Google Test:

Isn't it concise?

Selenide API

Poor software doesn't have documentation.

Brilliant software doesn't need documentation.

We are proud to claim that Selenide is so simple that you don't need to read tons of documentation.
The whole work with Selenide consists of three simple things!

Using Selenide is as simple as: $(selector).do()

Use the power of the IDE

Selenide has been designed to be very easy usable from any IDE without the need for reading documentation. You just write $("selector"). - and the IDE suggests all possible variants once you pressed the dot.

You can even start typing some word - say, "ente" - and the IDE suggests all possible methods containing "ente" - "pressEnter" in this case.

Ajax and timeouts

The most annoying problem of UI Tests is timeouts. Testers live in a world without Ajax in their dreams. The test that you wrote today can work tomorrow, and next week, and even next month, but sometimes it will fail, just because the CI server is in a bad mood. Some Ajax request took a little bit longer time than before; some JavaScript happened to be a little bit slower; another process was run at the same time with your tests and occupied server CPU - and boom, your test is red! We spent a lot of hours if not months digging in these problems.

The typical solution is to use "sleep" or "wait_until" methods in your test. Though it usually helps, we do not live in "sleep world" in our dreams! Ideally, we should concentrate on business logic when writing tests, without the need to bother about WebDriver lifecycle, timeouts, sleeping, waiting etc.

With Selenide you can concentrate on business logic. Forget Ajax!

How it works?

You are probably surprised about the simplicity of the solution provided by Selenide against the timing problems. No sleeps and waits anymore! Every should method just waits for a few seconds if needed.

When you write

$("#menu").shouldHave(text("Hello"));

Selenide checks if the element contains "Hello". If not yet, Selenide assumes that probably the element will be updated dynamically soon, and waits a little bit until it happens. The default timeout is 4 seconds, which is typically enough for most web applications. And of course, it's configurable.

In the example above, you can see that with Selenide you can check that an element does NOT match the criteria: element is not checked, element does not contain "error" word, element has disappeared. This would take multiple lines of code including try/catch with pure Selenium. With Selenide you can do it with just one line of code.

Screenshots

Screenshots can help in case of any problems with UI Tests. They can also be used in reports, documentation, demonstrations etc.

Selenide allows you to take screenshots after every failed test and after successful tests also if you want. You can do it with just one line of code:

Working with collections

Sometimes it's useful to check the whole list of elements - say, rows of a table. Selenide allows doing it with one line of code using $$ method:

The $$ method returns collection of elements that can be checked against some criteria.

Page Objects

QA engineers love Page Objects. Every time I speak about Selenide the first question is: "Does Selenide support Page Objects?"

The short answer is: yes, Selenide supports page objects.

The long answer is: page object is not a thing that needs some special support. Test engineers are accustomed that their page objects need to extend some superclass, and use @FindBy annotations, and pass WebDriver instance to the constructor, and use PageFactory to initialize elements, etc.

It's a crap!

All this stuff is needed only because of lack of concise API. With Selenide you have got a concise API, therefore you do not need to do anything special to use page objects. No annotations, no page factories, no super-classes. Just encapsulate logic of elements and pages to separate methods and classes, as in any other kind of programming.

Watch this:

It's a page object for GoogleTest that was present in the beginning of this article. As you see, it doesn't need neither annotations, constructor, PageFactory nor WebDriver instance. It's just a class that encapsulates logic of working with elements of a page. That's how developers should create domain objects, and that's how testers should create page objects.

By the way, this is how the test using GooglePage object could look like:

Customization

There is an opinion that the primary failure of many tools (like Maven) is the impossibility to customize behavior. You can write your own plugins for Maven, but you cannot change the order of lifecycle phases in your build.

Inspired by Martin Fowler's "Internal Reprogrammability" article, we designed Selenide so that every little piece of its logic can be easily customized. There is no private methods in Selenide, you can supplement or override any method.

For instance, if you don't like how Selenide takes screenshots, you can override this logic by providing your own version of ScreenShotLaboratory:

Selenide in Scala

As a Java library, Selenide can be used in any JVM language.

This is how ScalaTest+Selenide looks like:

Selenide in Groovy

Tools similar to Selenide

Selenium WebDriver is a browser driving tool, not a testing tool. That's the reason why several tools have been created on top of Selenium like Thucydides, Yandex HtmlElements, fluent-selenium, FluentLenium, Watir-webdriver to name some of them. Selenide is one of them.

I am often asked about Selenide competitors. We are not competitors. We all do carry the same mission. If you write effective automated tests for your application, I am already happy, whatever tool you use for this. We created Selenide for those who appreciate simplicity, conciseness, expressivity and clean code.

You code it - you test it

At the end I want to deliver a really, really important message to you. No one tool in the world can make your development effective - methods can. The name of this journal is "Methods & Tools", but the methods are the most underestimated.

Why developers should write automated tests.

We really believe that software developers should write automated tests by themselves. It makes them feel the responsibility for the code. And it allows them to safely change the codebase that immediately leads to higher quality of code.

And the main goodness for tests is that developers create a simple architecture and clear design when they are forced to write tests first.

Compare:

• Poor testers need to open login page, write username and password and click login button 1000 times before every test. It makes tests incredibly slow.
• Developers create a "/fakeLogin/as/john.smith" URL that works only in test environment, and allows to login as any user faster than your eyes blink.

And even more,

• Poor tester writes 20 UI tests that try to login with 20 different invalid emails in order to assure that email validation works. These 20 tests take the whole minute.
• Developer writes 2000 unit tests that tests email validation in 0.1 second. And one UI tests that verifies showing of error message on the login page.

Testers just cannot do it as they treat the system as a black box. That's the reason why developers should help them by writing (at least some) automated tests by themselves. In this case developers create a testable architecture.

Happy coding, with right tools and right methods!

References

Selenide homepage: http://selenide.org

Selenide Harlem Shake: http://selenide.org/2013/08/29/selenide-harlem-shake/

Article about Selenide in RebelLabs (16.10.2013): http://zeroturnaround.com/rebellabs/if-you-use-selenium-for-browser-based-ui-acceptance-testing-you-might-like-selenide/

Selenide presentation at Nordic Testing days (6.06.2013): http://selenide.org/Valdo Purde Workshop Automated testing with Selenide.pdf

Marting Fowler, "Internal reprogrammability" (10.01.2013): http://martinfowler.com/bliki/InternalReprogrammability.html

---

More Software Testing Knowledge

Functional Testing Tools

Software Testing Magazine

---

Click here to view the complete list of tools reviews

This article was originally published in the Winter 2013 issue of Methods & Tools