4 ms·
Full disclosure: I'm working on a product that's designed to eliminate the pain points of Selenium. On point four, a lot of companies aspire to having great te
by donaltroddyn 9y ago
Full disclosure: I'm working on a product that's designed to eliminate the pain points of Selenium.
On point four, a lot of companies aspire to having great test suites, which these days for user-facing apps often means aggressive unit and API testing on the backend, and using browser tests for end-to-end or integration tests. We're seeing companies moving away from running comprehensive functional tests in the browser because they take so long to run, and tend to be very brittle.
When it comes to writing browser tests, Selenium is still the most common tool for browser automation, but especially with the advent of Chrome Headless, there's a whole slew of new tools popping up (and there are lots of commercial tools like SmartBear's TestComplete or Telerik TestStudio). Selenium is not very popular, because it can be a pain to write the tests, and they tend to rely heavily (although it depends on how they're written) on addressing elements with XPATHs or CSS selectors, which are very brittle - especially in large teams or where the front-end is changing a lot.
It's also hard to get devs to write Selenium tests. It's tedious work, and they often need constant maintenance, so enterprise usually have dedicated test automation engineers, who are hard to find and tend to move on to better roles as soon as they can.
- megamindbrian2 9y agoI actually enjoy selenium. I would like to contribute. I am working on a "smoke tester". Something that is goal oriented and will iterate through every non-destructive action to reach an outcome. It then minimizes the steps to reach the goal. I've created a "grid" without using any grid features. All you really need to do is keep track of the session IDs on the client. This is the code in nodejs. https://colab.research.google.com/notebook#fileId=0B0MRKlXGDUMOT3Q5eXp3RVZjdUE https://colab.research.google.com/notebook#fileId=0B0MRKlXGD...
- megamindbrian2 9y agoWe should probably work together on this. I imagine a test looking more like "login with username and password", where the command "login" breaks out into an XPath like "//a[contains(., 'log in')]|//a[contains(., 'login')]|//a[contains(., 'sign in')]|//a[contains(., 'already')]" and the path to get there might include queries like "//a[contains(., 'account')]|//a[contains(., 'register')]|//a[contains(., 'sign up')]" . All of these would be considered safe/"non-destructive" actions.
- donaltroddyn 9y agoI'm happy to discuss this in more detail - my contact details are in my profile - but the product I'm working is currently in public beta and we're venture funded. We're taking a slightly different approach in that, in your example login form, we're using ML classifiers and some NLP techniques to pick the most likely candidate username and password fields, and if we get it wrong, you can correct us which then feeds into the training data. We have free accounts if you'd like to try it out, at https://developer.unravel.io https://developer.unravel.io . It'd be great to see if the user experience from a developer's perspective is close to what you're imagining.