3 ms·

I'm the founder/CTO at Unravel, where we're working on using machine learning to solve this problem. Unravel lets devs write tests using our declarative DSL and

I'm the founder/CTO at Unravel, where we're working on using machine learning to solve this problem. Unravel lets devs write tests using our declarative DSL and we generate the browser tests at runtime, using ML for element classification & expert systems to determine sensible actions. You can either give us explicit inputs or use predefined data profiles (ie, complete a form with dummy details for a U.S. user with a test Mastercard, etc). The dynamically generated at runtime tests solves the weak locator problem, and it's smart enough to avoid inputing invalid values in input fields. We deal with page loading well, and we're working on being able to automatically deal with alerts (and other modals). The result is browser tests that are way faster to write (because you don't have to worry about locators), and the tests are way more resilient. We're currently pre-release, but we're looking for companies and devs who'd like to be in our upcoming alpha.

HashHishBang 9y ago
Wait is there actually demand for something that...I guess powerful? Applying ML to Selenium selectors seems like some truly massive overkill. Not to mention dynamically generated tests at runtime. I'm not really sure how that would solve the problem of a weak locator. If you're given explicit inputs and they're weak enough to break then building a reliable test from that seems a tremendous challenge. I love that you guys are having a go at this problem. I do this kind of regularly. The claims of being faster to write due to not having to figure out locators doesn't seem to hold water though.
- donaltroddyn 9y ago
  Well, instead of having to explicitly fill each field in a form, you can just say "Fill the personal details form" or "Fill the credit card form" and we'll work out what each field is and fill it with sensible inputs - either dummy data or data supplied by the test author. Since you aren't hard-coding each locator, and we determine what fields are present and how to deal with them at runtime, unstable ids, classes, & xpaths, and even adding/removing form fields can be handled gracefully (as long as the user journey doesn't change semantically). We can also handle other common actions like "Login", "Search for ipsum", "Select the first search result" (or "Select the first product/hotel/flight/etc" - that one's really impressive), "Add to cart", "Checkout". When writing the tests, we give you the list of imperative actions than we think your declarative commands map to, and you can correct us if (when) we get it wrong. We also have some value-adds. Apart from the usual assertions (checking the page loads, looking for certain text or elements, et cetera), you can write assertions checking for the presence and correctness of 200+ advertising and analytics tags, and can included computed assertions (assertions that are computed from the context of the test). We also have natural language date handling, so you can write evergreen tests with commands like "Search for a flight next Monday" and we'll resolve that to the actual date to input into the datepicker. We're also working on malware detection (basically checking all loaded resources and outbounds like on every page we load for suspicious markers).
  - HashHishBang 9y ago
    Wow, that's really impressive. Good on you all for putting in the work.
    - donaltroddyn 9y ago
      Thanks, but literally all the hard work has been done our dev team - not me.

HashHishBang 9y ago

Wait is there actually demand for something that...I guess powerful? Applying ML to Selenium selectors seems like some truly massive overkill. Not to mention dynamically generated tests at runtime. I'm not really sure how that would solve the problem of a weak locator. If you're given explicit inputs and they're weak enough to break then building a reliable test from that seems a tremendous challenge. I love that you guys are having a go at this problem. I do this kind of regularly. The claims of being faster to write due to not having to figure out locators doesn't seem to hold water though.

donaltroddyn 9y ago
Well, instead of having to explicitly fill each field in a form, you can just say "Fill the personal details form" or "Fill the credit card form" and we'll work out what each field is and fill it with sensible inputs - either dummy data or data supplied by the test author. Since you aren't hard-coding each locator, and we determine what fields are present and how to deal with them at runtime, unstable ids, classes, & xpaths, and even adding/removing form fields can be handled gracefully (as long as the user journey doesn't change semantically). We can also handle other common actions like "Login", "Search for ipsum", "Select the first search result" (or "Select the first product/hotel/flight/etc" - that one's really impressive), "Add to cart", "Checkout". When writing the tests, we give you the list of imperative actions than we think your declarative commands map to, and you can correct us if (when) we get it wrong. We also have some value-adds. Apart from the usual assertions (checking the page loads, looking for certain text or elements, et cetera), you can write assertions checking for the presence and correctness of 200+ advertising and analytics tags, and can included computed assertions (assertions that are computed from the context of the test). We also have natural language date handling, so you can write evergreen tests with commands like "Search for a flight next Monday" and we'll resolve that to the actual date to input into the datepicker. We're also working on malware detection (basically checking all loaded resources and outbounds like on every page we load for suspicious markers).
- HashHishBang 9y ago
  Wow, that's really impressive. Good on you all for putting in the work.
  - donaltroddyn 9y ago
    Thanks, but literally all the hard work has been done our dev team - not me.