Thanks @triangleman, the multi-human languages feature has just been added in the latest release. There'll probably be edge cases which I couldn't encounter during testing. The tool is essentially like a macros library to minimize writing code and make automation of UI interactions easier. Appreciate feedback from the community!
Hi! I'm Ken from Singapore. TAGUI FEATURES • automate Chrome, Firefox, PhantomJS • visual automation of websites and desktop • write in 20+ human languages & JavaScript • Chrome extension for recording web actions • unzip and run on macOS, Linux, Windows • run by schedule, command line, API URL • advanced API / command calls to services
I left banking to do these open-source automation stuff full-time a year ago, partly out of interest and partly to dedicate time for self-directed learning. Tomorrow, I'll be moving back to full-time job at AI Singapore (https://www.aisingapore.org). It's a government initiative to build up AI capabilities locally. During my role there, integrating the tool (in its current form or a new form) with AI and ML capabilities will be part of my job scope.
Thanks Ben, it's been a while since we last spoke :) Yeah it's probably ok, I've extended the language parsing engine so that users can write automation scripts in their 21 different native languages. The language definitions can be easily improved or added by users.
Here's the current set - Bengali, Chinese, English, French, German, Hindi, Hungarian, Indonesian, Italian, Japanese, Korean, Polish, Portuguese, Romanian, Russian, Serbian, Spanish, Tagalog, Tamil, Thai, Vietnamese.
My background is in test automation (on user interfaces). Is it correct to say in ML the concept of test automation is irrelevant? Because during training and predicting the model is already being validated for accuracy and correctness.
Hi HN folks, I'm from Singapore and starting a company specialising in web automation.
Web automation basically reproduces manual interactions you have with websites so that the computer can do it repeatedly for you. Common use cases are automating manual workflows to improve business productivity, gathering data for business intelligence, and web testing for agile development.
Rates are competitive at $18, €15, S$24 for a simple automation project. The automation can be quickly developed off-site or live on a call / video. More details in the link. Competitors are welcome to post here to share their services or tips, and help bring the web automation domain forward.
My goal is to offer another option to the RPA (robotic process automation) industry practice which takes a top-down approach. Too much bloat in the production and delivery process which gets passed on as high costs to customers (and arguably over-promised expectations). That makes it only possible for very large companies to enjoy benefits of RPA.
Hi bluepnume, if you are ok, can you share how you manage iframes and popups? I'm using DevTools protocol through websocket directly to communicate with Chrome. Have to do a lot of context handling (frames) and using Target.sendMessageToTarget (popup windows) to deal with them. These 2 features seem to be the harder to handle parts of the interaction layer when doing automation with DevTools Protocol. Thanks in advance!
There was still some commits in early July but haven't seen new updates till date. Maintaining a browser project is mammoth task. Even for an established startup such as Segment you see that NightmareJS has lots of issues unreplied for months. I guess it's primarily because of a potentially large user base and all kinds of edge cases requirements from different users. And add on to that, suppose to work on all OSes. Nightmare.
I didn't follow that development. Can you share why Selenium maintainers chose not to implement headers? Is it that they want to restrict the tool to simulate what a normal user can do with a browser and not hacks such as overriding headers? Thanks in advance!
Thanks Jason, enjoyed your thought-provoking post. I'm reminded of Parkinson's law that "work expands so as to fill the time available for its completion". It's as if the software bloats up to fill up the available hardware capacity.
From a fundamental level though, my hunch would be how modern development takes modularization / abstraction to a type of extreme. Imagine a popular Node.js module and how many dependencies it has and how many dependencies its dependencies have.
It's not hard to imagine a lot more computing power is required to handle this. But that's ok to decision makers, computing power is cheap. Saving developers time by using modularized developments brings more cost/profit benefits, like what Dan said.
PS: the link on Visual Studio. Oh wow, what fond nostalgic memories it brings me :)
I just recently got to know WebPageTest. It even has scripting abilities! I'm just surprised why the project didn't enter into mainstream (in the sense that an average test automation guy like me will know).
Actually the release of Puppeteer is a really exciting development. I've been waiting for some time for something like this to happen. We've seen what happened to PhantomJS (almost 2k open issues and main maintainer stepping down without a successor), NightmareJS (lots of unreplied issues for months, probably the project is not a strategic part of Segment) and so on. In theory it is great for an individual or an established startup to drive a web browser automation project. But in reality, the scope of web browser automation simply gets out of hand very quickly. There are just too much edge cases to support for a fast-changing domain.
Being driven by a large commercial entity actually has a chance of making it work out. With the browser automation tool and the browser dev team being one team, there can be synergies not possible otherwise. When I spoke to CasperJS creator some time ago, I can understand why there will be burnout. Referring to the popular Chromeless project launched less than a month ago, there are already 150+ new issues and 100+ still open, and they already have enough pipelines for a few releases ahead. It can be a nightmare to manage.
There's just too many needs from a large user-base for such projects. I'm speaking from the context of test automation and general browser automation.
(Hi Tim, I use your GitHub corner :) thanks for making it) - There are still some differences between Chromium and Chrome, for example the case of playing back MP4 video due to paid licensing. But Puppeteer being easily configurable to use Canary or an existing Chrome installation addresses this gap.
Puppeteer automates headless / visible Chrome today. However, the foundational way it does this is through DevTools Protocol. I believe it might be browser agnostic in time to come. There are various (some successful, some failed) adapters for bridging DevTools Protocol to IE, Edge, Firefox, Safari etc. So I really do think supporting cross-browsers is not an impossibility.
But resonated with your point that there are just so much codebase / automation assets already written. Usually exploring new tools happens when a new project happens, rather than recoding entirely an existing project. For the existing code base, unless contributors from the community writes a parser to translate those to Puppeteer API?
I'm born 1981, so according to the article I've just made it to be a native? What I do observe is this (this is over-generalization but seems true to me) -
Pre-internet era - people know little but do a lot and deeply
Post-internet era - people know a lot but do little and shallow
Just got to know this, I have not tried it personally. It looks to be addressing a key pain point for test automation - the maintenance of existing test set to stay relevant to changing interfaces / identifiers etc. The part I really hate about test automation is the maintenance to always stay up to date with changes in the underlying webapp.
There's a section in the readme which I'm not sure of - "Running integration Tests for example is much faster." I guess that gains is from the parallel executions. But for the integration testings, there is still work to be done to make a central controller / runner to distribute various tests to different Lambda instances, correct? If that's the case, is loadtesting using Chromeless be another use case? Just initiate in parallel and blast the app infrastructure. It won't be efficient in terms of costs as using non-real browsers but this is probably as realistic as simulating real users load through real browsers.