I know the basics of optimizing Robot Framework for speed on normal applications, but this is not a normal application. It's not a question of going as fast as possible, because if the code executes too fast on an Angular application, it'll try to click an element that isn't enabled or visible, or an element that doesn't exist yet. Timing issues abound, and the result is that I'm using a keyword (below) to slow down my program universally. The problem is that it's hard-coded, and I'm looking for a more "programatic" (programatical? I don't know the exact term) solution that will wait for an element to be clickable and then click it as soon as it is.
This is the keyword I use after every single click (${SLOW_TIME} is a global variable set to 0.5s):
Slow Down
# EXAMPLE USAGE
# Slow Down ${SLOW_TIME}
[Arguments] ${SLOW_TIME}
Sleep ${SLOW_TIME}
This is my current solution, which was written to verify that an element is ready to be clicked for test verification purposes, not speed. It's not complete (needs "Is Clickable") and occasionally causes the program to wait longer than it has to:
Verify Element Is Ready
# EXAMPLE USAGE
# Verify Element Is Ready id=myElementId
# Click Element id=myElementId
[Arguments] ${element}
Variable should exist ${element}
Wait until element is visible ${element}
Wait until element is enabled ${element}
I'm aware that Robot Framework isn't built for speed, but for long tests I'm tired of doing nothing for 10 minutes waiting for it to finish, only to see that I have an incorrect [Fail]. If the solution involves Python, Javascript, or Java, I can work that in.
EDIT: I'm currently using ExtendedSelenium2Library, but its implicit waits don't always work, so I wanted a second layer of waiting, but only as long as necessary.
First solution to explore would be to use libraries specifically designed for Angular based web applications, such as AngularJsLibrary or ExtendedSelenium2Library. As far as I know, ExtendedSelenium2Library is the one that works best (but perhaps not without any issues, I think it does have a few issues)
Next thing to know is, given that your element indeed is visible, it doesn't necessarily mean that it's ready to be clicked. There are quite a few ways to get around this kind of issues.
One way is to put a sleep in your test setup, to give the page some time to fully initialize. I'm personally not a fan of this solution. This solution also doesn't work well for pages that load new content dynamically after the initial document was initialized.
Another way is to wrap your click element in a wait, either by writing your own in Python or, using something like Wait Until Keyword Succeeds
Related
I'm having a very frustrating problem with testing a React app using CodeceptJS and puppeteer - it only finds elements with a custom locator only when in paused mode.
My custom locator is data-test-id. I'm targeting elements using I.seeElement("$id-of-element-here") and I.seeNumberOfElements("$test-id", X).
This works perfectly when my tests are paused and I'm manually moving onto each step of the test, but does not work when the tests are executing from start to finish - targeted elements are simply not found.
Sometimes I can counter this with I.wait(X) or I.refreshPage() but I'm now running into a case where none of this helps.
I do see the data-test-id attributes in the HTML using both Chrome's and Chromium's dev tools. There are no typos either.
There's not much point in showing examples of targeted elements, as the problem seems to happen at random, I haven't been able to see any pattern of where/when this happens.
These are the settings of the custom locator plugin, in codecept.conf.js:
plugins{
...
customLocator: {
enabled: true,
attribute: 'data-test-id',
},
...
}
Any help will be appreciated! :)
May waitForNavigation is a way to go?
https://codecept.io/helpers/Puppeteer/#configuration
https://github.com/puppeteer/puppeteer/blob/main/docs/api.md#pagewaitfornavigationoptions
Solution:
I was running the assertions in question in a rather big within block (link), so I was ending up looking for something within an element that was no longer on the page.
It appears that during a pause(), you can find and operate on elements that are visible at the moment and the within blocks don't matter.
That's the only way I can explain why, in this situation, an element can be detected during a pause but not during the actual execution of the test from start to finish.
As soon as I moved the assertions out of the within block, everything was normal and behaved as expected.
Apologies for the confusion - learning every day... :)
I have given a wait time for 60 sec, and i am using wait until element to be clickable/visible but script is waiting for whole 30 secs even though the element is visible on UI and also clickable?
I tried using latest selenium version, tried using different waits also using different locators. but it did not work
The reasons could be in:
The element belongs to iframe so you need to switch to the iframe prior to attempting locating anything inside it
The element belongs to Shadow DOM so you need to locate ShadowRoot object, cast it to the WebElement and find the sub-element you want to click
Your locator is not correct, try getting the page source and saving it to a file. Once done use your favourite browser developer tools to locate the elemen
The syntax of your Explicit Wait is not correct. Check out Explicit Waits and How to use Selenium to test web applications using AJAX technology for code examples
Going forward consider adding page source and your code to your question as the chance you will get the comprehensive answer will be much higher, otherwise we have to go for "blind shots"
Whenever I am going through the concept of implicit wait and explicit wait concept in selenium most often I come across the sentence "to poll the DOM".What exactly it means?? I searched in google to find but I didn't find the relevant answer.
It means to check the DOM repeatedly, on a set interval (every X milliseconds), to see if an element exists.
Basically, when using implicit wait, your web driver will "check" for an element of the DOM for a certain amount of time. While when using explicit wait, it will wait until it finds the element. A more clear distinction and maybe what you need can be found in this article:
So, An explicit wait is code you define to wait for a certain condition to occur before proceeding further in the code. An implicit wait tells WebDriver to poll the DOM for a certain amount of time when trying to find an element or elements if they are not immediately available
There are other questions on StackOverflow which are close to what I want to know, like Webkit GTK :: How to detect when a download has finished?, but I think I'm asking something a bit different:
In general, in the event-driven C Webkit-GTK API there are a lot of events which may relate to the idea of when some document is finished "loading". The problem is the documentation is pretty sparse, and the idea of "finished loading" isn't necessarily clear, because it can refer to a lot of things. Does "finished loading" mean that the document is finished downloading? That it's finished creating the DOM tree? That it's finished downloading including all other resources (like CSS, JS and image files?)
Relevant signals are signal::notify::load-status, document-load-finished, and resource-load-finished.
The load-status signal fires everytime the load status changes, so you need to manually call webkit_web_view_get_load_status and check the status each time. Even so, when the status finally is WEBKIT_LOAD_FINISHED, I'm not sure what that means - does it mean WebKit is done downloading the resource, or that it's finished creating the DOM tree, or what?
Question:
What is the difference between the various "finished" signals, and is there any signal that is equivalent to the standard Javascript DOM event window.onload?
I believe the document-load-finished signal is what you are looking for as it seems (in my opinion) to match more closely what you are trying to test for.
One idea to test which is the correct way to do this would be to test the various ways there are to test if a document has "loaded" manually. I.e. Try the one I linked to above, and output a string to the Terminal when the value is true. If the value is true before the page has completely displayed all of its contents, chances are that it's not the one you're after. Then move on to the next, until you've got the right one.
Other than that, I'm not really sure what else you can do, since as you mentioned, the definition isn't very clear. It's times like these I wish Gtk documentation was a little more verbose.
how much time does it take to create a simple dance performing bot in second life using Linden Scripting Language ?? , i have no prior knowledge of lsl , but i know various object oriented and event driven programming languages .
Well, it's pretty simple to animate avatar: you'll need a dance animation (those are pretty easy to find, or you could create your own), put it in a prim (which is basic building object in SL), and then create a simple script which first requests permission to animate desired avatar:
llRequestPermissions(agent_key, PERMISSION_TRIGGER_ANIMATION);
You receive response in run_time_permissions event and trigger your animation by name:
run_time_permissions(integer param)
{
llStartAnimation("my animation");
}
Those are the essentials; you'll probably want to request permissions when an avatar touches your object, and stop animation on second touch... or you could request for permissions for each avatar which is in certain range.
As for the "bot" part, Second Life viewer code is open source; if you don't want to build it yourself, there are several customizable bots available. Or you could simply run an official SL viewer and leave it on; there is a way to run several instances of SL viewer at the same time. It all depends on what exactly you need it for.
Official LSL portal can be found here, though I prefer slightly outdated LSL wiki.
Slight language mismatch: To make an object perform a dance is currently known as "puppetry" in a SecondLife context. The term "bot" currently means control of an avatar by an external script api.
Anyway in one instance, it took me about two hours to write, when I did one for a teddy bear a few weeks back, but that was after learning alot from taking apart some old ones, and i never did finish making the dance, it just waggles the legs or hugs with the arms, but the script is capable for however many steps and parts you can cram in memory.
Puppetry of objects has not improved much in the past decade. It is highly restricted by movement update rates and script limitations. Movement is often delayed under server load and the client doesn't always get updates, which produces pauses and skips in varying measure. Scripts have a maximum size of 64k which should be plenty but in actuality runs out fast with the convolutions necessary in lsl. Moving each linked prim in an object seperately used to need a script in each prim, until new fuctions were introduced to apply attributes by linknumber, still many objects use old scripts which may never be updated. Laggy puppets make for a pitiful show, but most users would not know how to identify a good puppetry script.
The popular way to start making a puppet script is to find an older open source puppet script online, and update it to work from one script. Some archane versions are given as 'master' and 'slave' scripts which need to be merged placing the slave actions as a function into the master, changing llMessageLinked( ) for the function name. Others use an identical script for each prim. I said popular, not the simplest or easiest, and it will never be the best.
Scripting from scratch, the active flow needs to go in a timer event with nothing else in it. Use a different state for animating if a timer is needed when waiting because it's a heavy activity and you don't need any more ifs or buts.
The most crucial task is create a loop to build parameters from a list of linknumbers, positions, and rotations into a parameter list before the llSetLinkPrimitiveParamsFast( ). Yes, that's what they called it because it's a heavy list based function, you may just call it SLPPF inworld but not in the script. Because SLPPF requires the call to have certain constants for each parameter, the parameter list for each step will need to include PRIM_LINK_TARGET, linknumber, PRIM_POS, position, PRIM_ROT, rotation for each linked part in the animation step.
Here's an example of putting a list of a single puppetry step into SLPPF.
list parameters;
integer index;
while ( index < total ) { // total number of elements in each list
parameters += [
PRIM_LINK_TARGET, llList2Integer( currentstep, index ),
PRIM_POS, llList2Vector( currentstep, index+1 ),
PRIM_ROT, llList2Rotation( currentstep, index+2 )
];
index += 3;
}
llSetLinkPrimitiveParamsFast( 0, parameters );
How you create your currentstep list is another matter but the smoothest movement over many linked parts will only be possible if the script isn't moving lists around. So if running the timer at 0.2 seconds isn't any improvement over 0.3, it's because you've told lsl to shovel too many lists. This loop with three list calls may handle about 20 links at 0.1 seconds if the weather's good.
That's actually the worst of it over, just be careful of memory if cramming too many step lists into memory at once. Oh and if your object just vanishes completely, it's going to be hanging around near <0,0,0> because a 1 landed in the PRIM_LINK_TARGET hole.