Question about next steps for the GUI Attachment API

31 views
Skip to first unread message

Michael Depuy

unread,
Dec 3, 2012, 1:09:25 PM12/3/12
to se-bu...@googlegroups.com
Hello David,

I saw in the plugin documentation that there are plans to add the "Add/remove element in step" API call.  Do you know when this feature might be available? We are looking to write a plugin which will customize the plugin so that our QE and Product Management staff can export human-readable test cases.  I've copied and extended the english.js format file which worked great.  The next thing I am looking to do is add an optional field for each step so that a more readable label can be used instead of the locator value.  I got this to work by updating the __stepData object in selenium2.js for now:



Michael Depuy

unread,
Dec 3, 2012, 1:20:17 PM12/3/12
to se-bu...@googlegroups.com
Just realized I could add the additional parameter by updating the StepType.getParamNames() method.  This was easier than updating each step.

getParamNames: function() {
    var paramNames = builder.selenium2.__stepData[this.name];
    if(paramNames[0] == "locator") {
      paramNames.push("testCaseDisplayName");
    }
    return paramNames;

Zarkonnen

unread,
Dec 4, 2012, 1:40:12 AM12/4/12
to se-bu...@googlegroups.com
Hi Michael,

So the "add/remove element in step" feature is for creating additional UI components in the step display. This would work by registering a callback to be called each time the HTML for a step is created, and would probably need to work in tandem with other callbacks to indicate when step data has changed. This would allow for cleanly adding new UI elements to each step displayed. Is this the kind of thing you'd require for your plugin? If so, I'll schedule it in for the next update, and create some API stubs for you to comment on.

You might unfortunately come upon some issues with adding a new parameter in this way: the current maximum number of params a step can have is three - but this is another thing I can improve upon.

Let me know how you get on with development, and what else you need.

- David

Michael Depuy

unread,
Dec 5, 2012, 8:04:46 PM12/5/12
to se-bu...@googlegroups.com
Thanks for the response David.  The callbacks you described is exactly what I had in mind for our plugin.  We can get by without it for now but thanks for trying to get it into the next update.

I am also looking to extend the plugin so that it sends the pass/fail result to SauceLabs.  Any advice for me before I start that endeavor?

Zarkonnen

unread,
Dec 6, 2012, 9:53:41 AM12/6/12
to se-bu...@googlegroups.com
On 6 Dec 2012, at 02:04, Michael Depuy wrote:

> Thanks for the response David. The callbacks you described is exactly what I had in mind for our plugin. We can get by without it for now but thanks for trying to get it into the next update.

I'm currently engaged with trying to get window/frame/dialog support to work in local playback, so I can't give you an estimate yet - but I'll notify you when I have a working prototype of the code. :)

> I am also looking to extend the plugin so that it sends the pass/fail result to SauceLabs. Any advice for me before I start that endeavor?

Can you elaborate on that? If you're sending stuff to the sauce APIs, I guess you could store the login credentials in the same way as the existing Sauce plugin: https://github.com/saucelabs/sb-sauce-plugin/blob/master/sauce/plugin.js#L46
Reply all
Reply to author
Forward
0 new messages