Subscribe
Sign in
UI-licious for Teams — Test user journeys, not HTML, catch bugs before users do
UIlicious is a low-code tool for automating tests for your e-commerce websites and SaaS web applications with UI-licious. In this newest update, annotate test reports to highlight issues and discuss what's wrong. No more pointing and gesturing at screens!
7
Replies
Best
This looks interesting! How do you make sure that tests keep working once they've been authored, though, if they're mostly based on the displayed text?
@royjacobs , great question!
Our philosophy is "Test User Journeys, not HTML", because we want you to write readable and maintainable tests. UIlicious supports many ways to target an element, but has a strong bias to target elements based on displayed and assistive labels.
The UI-licious test engine target elements based on their displayed labels, assistive labels, semantic attributes (e.g. name, title, placeholders), but also conventional CSS and XPATH selectors.
For example, to fill a "Username" text field, you could write:
`I.fill("Username", "royjacobs")`
And UIlicious will search the page for a visible text input field that would likely be the "Username" field, based on the any elements attached to the input field, or any assistive labels set using the ARIA- attributes, or semantic labels such as "name" or "placeholder" attributes, or even nearby text that say "Username".
You can also use CSS / JQuery selectors, like this:
`I.fill("#username-input", "royjacobs")`
Or XPATH selectors, like this:
`I.fill("//*[@id='username-input']", "royjacobs")`
But unless your testing and development teams have established conventions to give each page element a unique element ID, we do not recommend using CSS and XPATH selectors, as they become difficult to read and maintain, and very difficult for new testers to be onboarded into the project.
Hey Portia!
Yea, I think even for engineers, Selenium test can be a challenge to setup and maintain.
Great question!
I would say UIlicious more geared towards making test automation accessible to non-coders, but at the same time, we don't want to sacrifice flexibility for engineers to get creative in the name of simplification.
When @picocreator and I first thought about creating UIlicious, we wanted to make sure it as easy to use for folks in the product development team that don't code, such as the product managers, designers, or manual software testers. I'm quite proud to say that as we've accomplished this mission as 70% of the tests created by our users are written by non-coders.
But as programmers ourselves, we want to make sure that it is still possible for programmers get creative, and use javascript natively to handle more complex test scenarios. I've tried codeless testing tools in the past and always struggled with trying to modify tests that were created by non-coding members of my team, even for simple things like generating relative test dates or randomised IDs. In UIlicious, engineers may use native Javascript along with the simple UIlicious test commands to do almost anything!
UI-licious