make tagui microsoft friendly & future plans

[kensoh]

ISSUE - execution engine now runs on macOS and Linux. FIX - after gathering and acting on feedback for beta release, port execution engine and dependencies to Windows

[c-h-]

@kensoh this project looks really amazing and the goal is laudable. I've taken a look at getting this work on Windows. It appears to me that the core programs required (phantomjs and casperjs) are cross-platform, so the only things required to get it to run would be porting the Bash script src/tagui and potentially the PHP to something more friendly for Windows.

Is that accurate? Have you considered doing this in Node? If it was done that way then anyone could install it with an npm command and it would execute on any machine that has Node installed, or from a USB stick.

I might try to port it in that direction in a fork unless you note there's an issue with the approach.

[kensoh]

Hi @c-h- thank you for your kind words :) Yes what you said is exactly correct, as far as I can tell now, it is the porting of src/tagui into a batch file, updating PHP files to handle Windows path '\' instead of the current codebase purely using '/'. There is a lot more work than these 2 areas that I can see now, waiting to appear along the way, and be addressed to work well for Windows users.

Do you mean packaging TA.Gui in Node? Actually I haven't used Node. Just signed up on npmjs and installing Node. Thanks for your suggestion!

[kensoh]

Hi @c-h-, adding on for reference, I missed out src/tagui_crontab - this file runs service requests batch if that system is used as a webserver to allow invoking automation flow execution via API.

If you have time to port it in that direction you mentioned that would be great! I'm now focusing on making the Chrome extension more expressive and improving the condition handling portion. I'll check back with you when I come back to work on the Windows portion so that we don't duplicate efforts.

[c-h-]

@kensoh so I had some free time today and forked the repo to try a different approach. I chose to use Node to repackage the whole thing since I'm most familiar with it. I also know professionally how well it works cross-platform including off a flash drive - I'm not sure if PHP shares those capabilities or not. I ran this port off a flash drive to test it and everything ran smooth.

My Node port is functional I believe, though I hardly tested it on anything.

Some perks of the port to Node:

• The code was easy to translate since bash, PHP, and Javascript are all scripting languages
• No need to maintain files for multiple platforms if it's all built in Node (no bash/bat)
• The whole thing is installable with a git clone and npm install (don't need to worry about phantom, casper, or slimer, those are handled as npm packages.)
• If this was published on NPM (easy to do) then installation to run the whole thing would be as simple as: npm install --global ta-gui. Then can run ta-gui <pathToFlowFile> [options] from anywhere.

Cons:

• Requires Node to be installed to run it
• The "core" parser/casper execution was ported just to get it working but most of the extra features and some intents have yet to be ported

I intend to play with this project and the Node port and see if it's worth continuing to work on it for my own needs.

Let me know what your thoughts are!

[c-h-]

By the way, check out the source code, particularly the intents parsing implementation: https://github.com/c-h-/TA.Gui/blob/master/src/js/tagui_intents.js#L197-L210

I think the Javascript multi-line template strings are more readable than you can do with PHP concatenation.

[kensoh]

Hi @c-h-, wow amazing work! I've starred your repo and would encourage developers more comfortable with Node implementation to do the same. I'm undecided whether for a typical user, installing Node or installing the packages separately is a lesser evil. I do wish to have the open-source deployment as simple as installing a Windows application, just double clicking into a .exe will do.

Can you describe briefly on how you port over to js? Is it manually editing each file or there is a way to automate part of that process? It'll be great if we can come up with automated porting. There are still much changes to be done from beta to the initial release and I'm much more familiar continuing the development and maintenance in PHP.

In fact the current codebase is very dense in that I try to pack as much code/text into each line as possible, while still formatting nicely and adding comments liberally. Reason being I work in a nomadic way with my wife, staying at different cities every few months, so it's just my laptop without monitor. I try to maximize screen real estate and optimize for development in vi editor so that I can rapidly code on the go.

Your idea is great and it makes automation more accessible if both implementations can be concurrent, only catch is that progress will be a whole lot slower if I were to switch to JS as the main engine. Nevertheless, let me know what I can help with while you work on porting to Node, be it through here or directly at support@tebel.org.

I've read through your documentation and following are some inputs fyi when I tried to run, I don't see any show-stopper. I tried using step show and it works. Tried echo it seems to throw some parsing error in the generated CasperJS script. Ran a second time and start getting below error:

executing casper
/usr/bin/env: node: No such file or directory

[kensoh]

@c-h-, an update that in the meantime I had setup npm distribution channel so that developers with Node can npm install tagui to get PhantomJS/CasperJS/SlimerJS also installed at the same time. This is not related to Windows portability, but may give developers a more convenient way to try out TA.Gui.

[c-h-]

@kensoh that's great - anything that makes it easier to use tools like this makes it that much more attractive. To be honest, I'll work on the Windows fork I started as I have time but it's really for a side project that isn't very important to me. I'll definitely keep you updated when I make contributions though! What would help me most is to have some example input files from the Chrome extension that use the various features of the parser, as well as the output that the parser generates. From that I can make sure the Node fork behaves identically in function as I have time so you don't have the errors you're reporting.

[kensoh]

Thank you @c-h-! This sounds like a good time to work on some unit-tests of sorts for tagui_parse.php, to cover different steps and conditions. I'm thinking of creating 2 signature files for it, one before parsing and one after. It'll help you validate and also useful for me to make sure nothing breaks when making changes or introducing new features. I'll work on this today and keep you updated.

Oh yes, adding another channel normally is bad and dilutes traffic, but my focus now is increasing downloads so that I can get more feedback on bugs/improvements. That will help the project better in the longer term. Npm appears to be a good channel for distribution, over 150 downloads since 2 days ago.

[kensoh]

Hi @c-h-, I've added into repo under src/test. There is a positive_test automation flow file. The idea is after running ./tagui on it the result should match positive_test.signature (I've replaced local filename with '/full_path').

This set of positive tests cover a much larger test set than the current iteration of Chrome extension. With these files my hunch is this is going to be the start of automated testing!

[c-h-]

Cool!! Looks great. To do automated testing I'd encourage doing Javascript minification on the parser output and the signature. Reason being that the JS that the Node fork generates has different whitespace than the PHP generated version etc while having the same functionality (for the working parts).

When I was implementing the fork I looked at diffs of the PHP generated version and the Node generated version to identify where the code was functionally different.

This signature should make it a lot easier to iterate though!!

[kensoh]

Thanks for your suggest @c-h-, I'll chew over it! I have reservations as minifying adds an extra layer of complexity for troubleshooting automated tests and adds dependencies. The workflow might be easier writing a wrapper to manage the whitespaces differences as part of the automated tests.

Past few days I had been thinking, are there merits in considering deployment on Windows using tools such as Babun? It provides the Linux shell and Linux-styled paths. Also, Microsoft is already introducing Linux shell into Windows 10 (for 64-bit version).

So I'm asking myself, is it better to maintain dual copies of code for execution engine, or focus efforts on improving existing features. In any case, I think I'll contact Babun's creator. Imagine installing Babun just by typing install and then along with that auto-download and configuration of PhantomJS/CasperJS/SlimerJS. That will be perfect!

[LeMoussel]

There is also MSYS2, that provide a bash shell, Autotools, revision control systems and the like for building native Windows applications using MinGW-w64 toolchains.

[kensoh]

Thanks @LeMoussel for sharing this tip! I'm checking MSYS2 out together with Babun and Cygwin.

If there is a way to let these shell platforms install with one click and automatically run scripts to install PhantomJS+CasperJS+SlimerJS, it sounds to me lesser user friction than having users install the dependencies separately. It also saves time porting/maintaining code for another platform, and that time can be focused on building up existing functionalities + new features.

[LeMoussel]

Grab the latest MSYS2 installer and go through the installer.
As of the latest version of MSYS2 you have to run msys2_shell.cmd -mingw32 or msys2_shell.cmd -mingw64 from the command line instead wherever you installed MSYS2 (i.e. C:\msys64)

A solution is to install build tools needed for PhantomJS, CasperJS & SlimerJS. You will need to use pacman to get these packages.
For PhantomJS

pacman -S gcc make flex bison gperf ruby openssl fontconfig sqlite libpng libjpeg git python perl
git clone git://github.com/ariya/phantomjs.git
cd phantomjs
git checkout 2.0
./build.sh

Another simpler solution would be to install applications using yaourt . Eg: yaourt -Ss phantomjs

[kensoh]

Thanks @LeMoussel this is looking good! Noted on your inputs.

With such command-line control through automated install script, non-developers and business users could enjoy the abstraction from PhantomJS / CasperJS, while tech users such as developers can enjoy fine-grain control over the installation process (manually or npm install tagui) and have the option of using JavaScript code directly within their automation flows.

[c-h-]

@kensoh just to chime in here, I was able to get PhantomJS, CasperJS, and SlimerJS fully locally installed and configured via npm. Once they're installed their paths are located at ./node_modules/.bin. Running casperjs commands etc. then just requires setting the environment variable so it can find the path to phantomsjs, slimerjs. Of course npm is needed to get these packages and that comes from installing Node, which is kind of a blocker.

[kensoh]

Hi @c-h- thanks for your feedback. Have you tried npm install tagui? I've set up the package to include CasperJS, PhantomJS and SlimerJS. The paths are defined in /src/tagui file with the following 2 lines.

CASPERJS_EXECUTABLE="/usr/local/bin/casperjs"
export PHANTOMJS_EXECUTABLE="/usr/local/bin/phantomjs"

Do you think you can help to validate if a fresh install usingnpm install tagui works out of the box or would it require changing the /src/tagui settings above? I did a sanity check but wasn't able to validate 100% on my VPS as I already had their global installations in place. I just assumed out of the 300+ downloads via npm someone will raise an issue here if it breaks.

If it does not work right out of the box I think I can adjust /src/tagui to detect whether it is invoke from Node.js installation and instead use the path you mentioned above.

Another consideration is the original PhantomJS is not deployed through npm due to technical reasons. The one on npm is built by someone from Medium and I guess is the defacto one used by Node.js users as well for convenience, but I am not 100% sure that package behaves exactly like the main PhantomJS package from the official website.

[kensoh]

am starting work on this. since beta release 3 weeks ago, much changes had been committed to resolve reported issues and strengthen the foundation of the tool. the chrome extension is also much more powerful and user friendly. as there are no more outstanding issues, am ready to cut a release candidate version as soon as the porting to windows is done.

to let windows users use the tool with minimal dependencies / installations, i will first try to go with porting the shell script to batch file and making the php file paths work for both windows and linux distributions. looking through, in theory there should be minimal maintenance effort once the base is set up.

for developers with node.js setup, the goal is for ta.gui to work directly with npm install tagui (appears to be already but need more feedback confirmation). for users without node.js setup, they are invited to download directly from phantomjs/casperjs/slimerjs websites and also have a look or learn more about those really cool tools at the same time. have updated readme for that.

i believe someone might create respective one-click installers for macos, linux, windows along the way. but not critical to be part of release agenda now. can't wait to distribute to a larger group of users to get more feedback and improve ta.gui!

[kensoh]

Well, I'm borrowing my wife's Windows laptop to use in middle of nights to get this over. And it really sucks to get the installations done on Windows. Install PHP, install CasperJS, install PhantomJS, install TA.Gui, config environment paths. I almost gave up. This is not going to work out.

I think many Windows users might just give up along the way if it's distributed this way. So, I'm going to attempt packaging all dependencies together as a zip file. Just download and run out of the box without any setup or any other dependencies. Can't see any roadblocks at the moment to distribute this way for Windows. So I'm gonna go for it.

Got the basic flow running (haven't ported the various options and file-handling). Aiming for this weekend or the next to cut the release candidate version which works on Windows/macOS/Linux.

[tomByrer]

Thanks for your hard work for we Windows devs!
Do you have a task list on how you installed it? But you're right environment paths can be a chore.

Perhaps a better solution would be a docker/rkt package, but let's get the manual install down first.

[kensoh]

No probs! A lot of businesses still run on Windows, definitely have to make it a breeze for Windows users or developers to run TA.Gui.

Yes it seems quite straightforward to package together, just put the PHP5-32bit-thread-safe + CasperJS + PhantomJS + TA.Gui files into a single directory and probably just append the paths and env variables accordingly in the main runner for Windows tagui.cmd

For Docker / rkt I won't rule out adding that distribution channel and automate the build/distribute process if some users can benefit from it. At the moment, there's only npm, direct downloads, using respective OS package managers.

Windows hopefully will be a one zip file download that works right out of the box. I hope to make a one zip file download for macOS too, and Linux if possible. Initially wanted users to manually set up the dependencies, but felt that it's so much hassle even before running the first automation file.

[kensoh]

Adding on, I also won't rule out having more than one endpoint for the automation. At the moment TA.Gui converts 'natural' language syntax into CasperJS JavaScript automation code.

But I would want to consider adding an option to also have the ability to convert to Selenium WebDriverIO if that is something useful by a substantial number of users. Since half of the project goal is make automation accessible to more people, it could mean non-developers and business users gaining the ability to write automation interactions without learning programming, it could also be for developers / QA to simplify their test automation development. I don't know if that will be a good feature to add, will look out for feedback.

At some point in time, depending on how it develops, probably have to decouple the parsing engine with parsing logic, so that through endpoints / language specific config files, the same automation flow file can output to multiple endpoints for consumption.

[kensoh]

Another 2 features I'm thinking about lately is 1) adding the ability to run automation flow from an URL so it is easy to share and reuse certain automations. 2) adding the ability to debug online by hosting a live session so when a user types the automation instruction through some interface, the step gets executed in real-time on his Firefox browser.

Don't see any technical roadblocks for the 2 ideas, just whether to implement and how they are implemented. These 2 features are something that I would want to use myself in a web automation tool, so probably have to get them implemented at some point in time.

[tomByrer]

convert to Selenium WebDriverIO if that is something useful by a substantial number of users

This would be most beneficial to corporate projects with a large code base & 1000s of tests. & perhaps such an addition should be sponsored by them? 💰

The other 2 ideas to good also, but perhaps another developer can create them?
Because I'd be more interested in making the tests/automation run faster, like using PHP7 or HHVM in the least, converting to CasperJS like you suggest (Node is good for fast I/O... Wal*Mart now uses it for all their websites AFAIK), or switching over to GoLang or Node.

My ideal world is test results return so fast they are nearly instantaneous, so I could code -- test - code - test back & forth so fast it is seamless work flow.

[kensoh]

I see.. I thought that Selenium WebDriver is the most commonly used test automation driver. If there are people benefiting it's probably not hard to add that option. The drawback is it might be an invitation to go down the rabbit hole. Because Selenium users might start asking for variants in Java, C# etc. That in theory should be manageable too if parsing engine is decoupled with language syntax and maybe contributors can just edit the config files for the respective endpoints.

I see.. Are you mainly testing web apps? From my experience with test automation, the bottleneck in test execution time is actually network latency in terms of the time the app web-server processes and return responses to users. The actual execution delay by various frameworks or methods are a small % compared to the total test execution time. I guess a quick and dirty way to make it superfast and run in parallel on multiple instances, that should bring the most gains with the least effort I think.

I like PHP language, in fact the parsing engine and API runners for TA.Gui is done in PHP. Its like some toolbox with many random things thrown inside, and so much can already be done without introducing new libraries / dependencies.

[tomByrer]

I think you're right, Selenium WebDriver does seem to be the most popular. However once you add something, you have to maintain it, & at least field suggestions to expand it like you fear.
Though making a solution more expandable by making it easier for others to add their own plugins/API is something I wish more do. If you feel TA.GUI already has a good plug-in architecture, then a quick docs/demo would help here.

To me, the difference between 'web apps' & 'web sites' is very small. I approach both with the same attitude that I want both to work as intended, load & run fast as possible. Also, with 'progressive web' & Google AMP websites are effectively web apps anyway. But yes, my main intention is to test local builds without a live remote API (maybe simulating an API with JSON dummy data.

Network latency is a good point, perhaps I should look into testing over Ethernet connected hardware running on their own local host? Parallel runs is also a good idea! (Though sometimes on my local machine my cores are eaten up by several graphics apps & browsers with too many tabs open to have too many other processes running also ;) )

PHP is cool. But it is unusual for web dev tooling to be PHP. Most of the libraries I've seen the past few years have been Node based, with some GoLang. They just run faster. I hope PHP7 or HHVM (or both) so people can run your tool at max speed.

Either way, thanks for your tool; I'm sure many will benefit from it! 🎆

[kensoh]

I posted to WebdriverIO gitter chat to get some feedback from the community. Their project head and an active contributor responded positively to make this addition. In that case, I'll add this to my agenda until some new developments discourage it.

Oh it is not yet able to 'plug-and-play' using config files. I'll basically have to tear the parsing engine apart and recode it to read the parsing syntax from respective config files. Eg 1 file for CasperJS, 1 file for WebdriverIO, etc. It is probably going to be a csv file for easy and convenient editing to show mapping abc TA.Gui step to xyz code for target endpoints.

However, during the process of ripping it apart and putting it back, there has to be a code freeze for that parsing engine. Otherwise it will be very easy to introduce bugs related to other new improvements or code changes. So I can only work on this after I get some confidence that there isn't anything new or bug-fix to be implemented in the near-term for the parsing engine. Ie, I need to get the foundation solid and the distribution packages for Windows, macOS, Linux working well first.

I have a friend @franciskim who is an expert on WebdriverIO and personally interested to see TA.Gui also output to that endpoint. When the 'plug-in' system is ready, I probably can create a draft syntax csv file base on what I know, and then invite him to review/edit and commit as contributor.

---

I see.. Oh yeah simulating with dummy API data can be very helpful if that component is not a critical part of the test suite. I remember last year in my testing team, we used 10 laptops each running 10 Firefox sessions to drive testing through Selenium Grid. We were not able to get past 10 sessions without experiencing sporadic side-effects of overloading the laptops.

PHP7/HHVM will definitely be an improvement, though actual savings in execution time would be minimal and a large % is actual response time from target web app. As an example, the Typeform automation flow to download a report. It takes about 1 second to parse natural language into CasperJS JavaScript + load the CasperJS & PhantomJS program, while the entire flow takes 20-30+ seconds depending on how fast Typeform website responds. So optimizing the language used by the parsing engine is probably going to return negligible gains.

Thanks for your encouragement! I've spoken to someone who wrote a very nice series of CasperJS / PhantomJS tutorials a few years back. He is looking into making a simple series for TA.Gui, that will be really helpful for people to get started, besides existing readme and sample flows.

[kensoh]

Started a new thread just for tracking and managing packaged installations.

The goal for that is users without Node.js can simply download a zip file for macOS, Linux or Windows. Just unzip and run TA.Gui, with no setup needed.

Maybe new kinds of issues will pop up, so proactively create a new issue to pre-empt - #20. All dependencies to be included already. More info at Set Up section of README.

[kensoh]

Windows file path handling is ok now with commit 6f9e14f and following commit comments -

• casperjs/phantomjs do not seem to support \ for windows paths, replace with / to work
• running manual js file directly with \ windows path for capturing images will throw phantomjs error
• replacing with \ with / for windows path can capture images and save correctly, thus this change

Running on Windows on an automation flow without options work now using tagui flow_filename, left on the table is options handling and the loop for handling datatables. Should be including in the TA.Gui Windows package some ports of Linux utilities such as awk and tee.

[kensoh]

Hi @c-h- @LeMoussel @tomByrer I've made a series of commits and I believe the port-over to Windows is completed. Check out the setup section for the packaged installation. Let me know if anyone runs into issues!

The method I chose was to simply port the Linux shell script into Windows batch script, plus handling some platform specific changes in the PHP code. Should be be easy to maintain after this initial effort. With this, there are a few areas where user friction is minimized -

• no need for Linux environments in Windows
• can package all dependencies for unzip & run
• also works for npm install tagui on Windows
• readme has manual setup steps if user wants to

I'll close this issue for now and keep issue #20 open (on tracking any issues with packaged installations for macOS, Linux, Windows).

[kensoh]

Hi @c-h- recently I added a live mode feature, so that during run-time user can type steps or JavaScript code to test interaction with web elements. In order to do that I have to 'duplicate' almost all the translation logic from PHP tagui_parse.php to JS in tagui_header.js. I remembered you were talking about that, but you might have moved on to other stuffs already.

Hi @tomByrer @LeMoussel it's been a couple of months since the packaged installations have been released. Do let me know if you encounter issues using! They suppose to work by just unzipping and run on macOS, Windows, Linux. All dependencies r packaged in. And also supports installation by npm install tagui. I ended up just porting over shell script to bash (lots of headaches) and including some Windows version of UNIX commands.

Now I'm working to integrate SikuliX so that visual automation can be supported. For example, clicking on an element by specifying an image file of what to look for. Proof of concept tests are ok, just need to code and test it. So this feature will be in v2.0 of the tool. I adding this mainly for cases where it is just not possible to automate through using XPath/CSS. This opens up a lot more possibilities. Because you can also interact with stuffs outside the browser, such as your desktop icons.

[c-h-]

yea @kensoh really excited you're still working on this and hope to dive in again one day. Right now it's not possible for me to contribute unfortunately. Best of luck!

[kensoh]

No probs @c-h- cya around again 😄 Thanks for your reply!

[LeMoussel]

Hi,@kensoh , Itou ! I'm actually on another project, it's not possible for me to contribute unfortunately.

[kensoh]

Going to try integrate headless Chrome directly with TagUI, raised an issue to track - https://github.com/tebelorg/TagUI/issues/24

[kensoh]

Done! Released v2.0 for direct Chrome automation for both visible and headless mode -
https://github.com/tebelorg/TagUI/releases/tag/v2.0.0