If you want to learn more on UI-licious is designed and how it works, read on below. Otherwise, click Next to jump straight in to get started.

Core philosophy of UI-licious

Unlike other end-to-end UI testing tools, UI-licious tests are designed to be independent from how the UI is implemented.

Why is this important you ask?

If you have used scripting tools like Selenium before, you'd probably have tests littered with ugly CSS and XPATH selectors and magic waits. If you don't know what CSS and XPATH selectors are, they are programmatic IDs for each and everything you see on the screen. This not only makes your tests hard to read and maintain, but also very fragile. Tiny changes to the design or the code of the UI will easily break your tests. Macro-recording tools make it easier for you to create tests without needing to how the UI is implemented, but generate tests in the same fashion and are just as fragile. And chances are, your UI is going to change, and it will probably change more frequently than the rest of your application too.

The UI-licious test engine is designed to make tests reliable, readable, and easy to maintain, by using simple pseudo-English, like the Github test above, and avoiding writing tests customised to implementation specifics. Writing tests this way also allows you to reuse tests on different UI designs.

We also believe that end-to-end tests should meaningfully describe your user's journey, because what else is the point of these tests then, if not to ensure that the app works, and ultimately deliver value to the user?

How does it work?

How does UI-licious know what you mean when you say I.click("Sign In")? What happens when "Sign in" appears multiple times on the web page?

No this isn't Powered by AI™ under the hood, at least not in the modern sense. The UI-licious test engine isn't a black box that magically figures how how your web application is meant to be tested. Unpredictable behaviour isn't exactly desirable when you are testing things...

UI-licious's test engine encoded with our years of personal experience in writing good and bad UI code since pre-JQuery era, and a bit of common sense. What happens when UI-licious loads up your web application is that UI-licious uses dynamic code analysis to determine how it should be tested based on the semantics of the code and what were the previous actions in the test. So when evaluating how I.click("Sign In"), UI-licious will be most inclined to click on a "clickable" element that best matches "Sign In" and is relatively nearer to the previous elements that was interacted with.

That said, if you are a developer, your UI code doesn't have to be perfect for it to be testable. But it certainly helps to use semantic HTML and ARIA accessibility attributes to indicate the intended use of an element.