extending intents/steps elegantly...

Hi Guys, I love the concept behind this and would like to start using tagui, however, it seems difficult to extend the steps…elegantly.

As an example, I would like to create some custom steps…

Step	Parameters	Purpose
login	username language	Login to app as a particular user and language e.g. login admin in fr
choose	element to select, value	select a particular value from a chosenjs selector (https://harvesthq.github.io/chosen/) example: choose category “classical music”

I could fork the project and then adapt for my own usage, but, that means I miss out on all the improvements from other users / contributors etc.

In the same breath, these custom steps would be project specific and we would tend to handcraft the tests rather than use the recorder.

I have an idea that may allow for extending the steps elegantly…

1. add an /src/steps folder with a steps_custom.inc file storing the step handlers

2. add `include_once(‘steps/steps_custom.inc’) to the first line of your tagui_parse.php file

3. here is an example login_intent that would reside in the steps/steps_custom.inc file

    /**
     * @file
     *   Custom steps can be declared in  here
     */
    function login_intent($raw_intent) {
      $params = trim(substr($raw_intent." ",1 + strpos($raw_intent." "," ")));
      $params = explode(' in ', $params);
   
      if (empty($params) || $params.length <> 2) {
        echo "ERROR - " . current_line() . " text missing for " . $raw_intent . "\n";
      }
      else {
        $return[] = 'casper.thenOpen("/?username=' . $params[0] . '")';
        $return[] = 'casper.thenOpen("user/setlanguage?lang=' . $params[0] . '")';
        return implode(PHP_EOL, $return);
      }

    }

1. change the functions in your tagui_parse.php to do something like this to loop through the intents…and parse correctly.

$script_line = trim($script_line); if ($script_line=="") return "";

	$step_intent = get_intent($script_line) . '_intent';
	if (function_exists($step_intent)) {		
		return $step_intent($script_line);
	}
	else {	
	  echo "ERROR - " . current_line() . " we cannot understand step " . $script_line . "\n";
	}

[dublindrupaller]

@klichukb Just saw your posts. Interesting stuff. FWIW, the main reason I like TAGUI is for the following reasons:

1. I joined a project that used selenium IDE (not webdriver) to build up a suite of a few hundred automated tests over a number of years to catch regression against new development in a continuous integration setup. Selenium IDE is currently not useable now with firefox making it extremely difficult to maintain and update those automated tests. A new selenium IDE maybe developed but that project is stuck in a bad place.

2. With TAGUI and the suggested approach I have put forward to @kensoh above in my previous comment, allows teams or individual engineers to “future-proof” their tests. In other words, if the project I joined used TAGUI, they would have a few hundred natural language tests they could simply switch to webdriver or puppeteer or other test script language framework. Instead of having to (a) choose a new framework that works…and (b) rewrite all those tests again in the new language.

3. In the same breath, the demo-for-ken branch I have created from TAGUI is only illustrative of the ability to switch languages. more work would be needed to allow TAGUI users to switch the language context from “casperjs”, which works on that branch as the default, to “puppeteer” or selenium “webdriver”.

As an aside…for me, puppeteer looks promising, but, is still in the early stages. My choice, after evaluating quite a number of other tools / frameworks is casperjs at the moment…the ideal scenario is to use TAGUI using casperjs now…with the ability to switch languages later if casperjs gets superceded by another framework.

hope that helps the discussion.

Gus

[dublindrupaller]

Hi @kensoh ,

I have been busy over the last few weeks…but I managed to sneak in some spare time to bring the suggested approach to a working demo stage. If you have a few moments, can you have a quick look at the linked readme which explains how it works.

I have added a readme to explain the concepts a bit better

The demo-for-ken branch works for simple tests (casperjs only).

I have migrated all the steps from your tagui_parse.php file into an object orientated class file structure to improve efficiency and performance, among other benefits. Ditto for the live mode tagui_headerjs output. (the readme linked explains how it works)

A few things I would like to do next:

1. At the moment the first line in a TAGUI test file must be a valid URL. I would like to add an URI option when running TAGUI. e.g.

 ../tagui gus.ui firefox --uri my.localhost.net
 ../tagui gus.ui firefox --uri my.system-integration-host.net
 ../tagui gus.ui firefox --uri my.uat-host.net

So the same suite of TAGUI tests can be run against different instances.

1. I would like to proceed with the idea of having a language context…the default at the moment is casperjs, but, I would like to extend that for puppeteer, webdriver and maybe other script languages. The readme linked above explains how that works.

2. I would like to refactor your javascript so I can minify the tagui_header.js includes for live mode etc. You use line endings a lot, rather than a semi-colon, so minifying the js is tricky when there are comments in there as well.

I appreciate you may have your own plans for TAGUI moving forward. If you think this is too much of a change, please let me know. You mentioned before that you think it maybe better to fork what I am doing into a new project, which is fine, but, I am a big fan of open source and I think TAGUI could benefit from an open source approach and increasing the usage /contributions. I think the suggested approach in the demo-for-ken branch allows for that but there is no problem if you would prefer to extend TAGUI as it is today.

Gus