sikuli-driver team mailing list archive

[RaiMan <rmhdevelop@xxxxxx>]

@Denis & Eugene
thanks for your valuable input.
additional aspect: there are surely different requirements for the use in a visual testing environment or for some automation.

For automation purposes you need reliable scripts, that even take care for some special situations, without crashing.
In testing it is ok, to just let a test fail, if something is not as it should be.

Automation scripts usually are tailored to solve a specific problem, usually for a fixed environment.
In testing today, the tests have to cover many system and rendering (mainly with browsers) environments.

In automation you want to be sure, that after some workflow step is processed, the intended operational result is achieved.
in testing usually the sequence is: when I do this, the GUI should look like that afterwards. And GUI testing often is separated from operational, data related testing (for which testers will surely not use a tool like SikuliX).

So a SikuliX recorder should surely support a sophisticated image capturing (naming, organising, optimisation, variants, ...).
With a little effort, this is possible already today:
- use the capture hotkey, which in most cases allows to capture the GUI elements in a way, as they are shown at runtime
- switch on the manual naming, so you can implement a naming convention from beginning
- separate code from images (code in one .sikuli, images, patterns and other image related information in other .sikuli), so you can decide at runtime which one to use via import

In my opinion it would be a step in the right direction, to force the
user, to first decide for the element's name and some attributes (only
image and/or an element that might be acted on by mouse and/or keyboard,
possible clickpoint relation to other images already in the stock, ....)
and then capture the image and store it in an organised way (image
groups).

-- 
You received this bug notification because you are a member of Sikuli
Drivers, which is subscribed to Sikuli.
https://bugs.launchpad.net/bugs/1434434

Title:
  [request] want a workflow recording tool with support for runtime
  adjustments to the workflow

Status in Sikuli:
  In Progress

Bug description:
  Hi guys!

  @RaiMan, could you kindly advise me if you have done a script
  recording tool? If you haven't, would you be interested in my one? It
  some kind of floating panel with two buttons Record and Stop, that can
  capture pictures and write your typing. Output is simply set of
  commands, for example:

  s.click("c:\\tmp\\myimgs\\PREF_20150320130001.PNG");
  s.type("H");
  s.type("e");
  s.type("l");
  s.type("l");
  s.type("o");
  s.type(" ");
  s.type("g");
  s.type("u");
  s.type("y");
  s.type("s");
  s.type("!");
  s.type(Key.ENTER);

  You can copy them and past to your code. Probably, I or someone else
  could develop a plugin for eclipse in the future that will input the
  commands directly to your code. By now, it will be an AWT application.
  The main advantage of the tool is to reduce necessity to make pictures
  manually and link them to the commands, the tool does it for you.

  I could also make an youtube video. So, let me know if you need so.

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/sikuli/+bug/1434434/+subscriptions