-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Avoid waiting for $timeout()s ? #169
Comments
You can use |
Hi @drhumlen , we had the same problematic and we conclude that the popup is definitely something that should go to unit testing. So, we mocked our notification system and expect that the mock has been called (eventually with some critical informations). We also unit tested the notification to be sure that nothing breaks. |
It now works great. But we have to be very conscientious and make sure that the popup is removed in some other way after each test (in our case, clicking the "x"-button):
@mackwic: I suppose it's possible to test it with a unit test for many apps, but in our case, the error messages are generated by the backend, so we have to test them in the e2e. Thanks @juliemr |
It seems strange that Protractor waits for |
Also faced this problem and solved it with I wanted to test save method and verify that success notification is displayed after save. This notification was getting hidden by $timeout service. Protractor was waiting for $timeout and checking if notification is visible after it already became hidden. Before:
After:
|
…e default issue here : angular/protractor#169
Is this not considered a valid issue? I just ran into this myself. I don't really see that using |
I also can't get this to work, even if I change to I have a toast that disappears after a timeout. This is the code I'm using to test it: username = element(select.model("user.username"))
password = element(select.model("user.password"))
loginButton = $('button[type=\'submit\']')
toast = $('.toaster')
# Check the toaster isn't displayed initially
expect(toast.isDisplayed()).toBe(false) # This passes
username.sendKeys("redders")
password.sendKeys("wrongpassword")
loginButton.click()
toastMessage = $('toast-message')
# Check the toaster is now displayed
expect(toast.isDisplayed()).toBe(true) # This passes
expect(toastMessage.getText()).toBe("Invalid password") # This fails The relevant markup is here (jade) .toaster(ng-show="messages.length")
.toast-message(ng-repeat="message in messages") {{message.body}} The failure is that |
Was this issue fixed yet? Because using interval instead of timeout is hack or workarounf more than solution. I face same issue and browser.ignoreSynchronization = true; does not help. I can replace code to $interval but e2e tests should test real code not the code adopted to them. |
@vytautas-pranskunas- sounds like there's a different issue for you if |
I figured out when I got two scenarios - in first
So as you can see it never sees element present because wait freezes when in touch with $timeout I really do not have so many time to make it reproducible in plunker but if you try to it would be great because this scenario should be quite common. Thnaks |
You log is really not very helpful without the context of the code that created it. Could you share that? |
I cannot share my code because of privacy but i can show some pseudo code to get an idea
and protractor part
browser.wait never finds that element because while element is present browse.wait is not triggering checks. |
Is there any progress or thoughts on this? |
Basicall using the `$interval` module. More details: angular/protractor#169 (comment)
Basicall using the `$interval` module. More details: angular/protractor#169 (comment)
Basicall using the `$interval` module. More details: angular/protractor#169 (comment)
Why "browser.ignoreSynchronization = false; " cannot be set immediately after the browser.wait()? My Code
|
+1 this bug has caused me so much misery. Please let's start a dialog on how to fix this. I have several dozen bower and npm angular modules that use $timeout, in hundreds(!) of places, as well as I use it 45 times in my code. Changing my code is feasible (and reasonable), however, changing third party code is totally out of the question logistically: contacting and trying to motivate upstream providers or locally forking third party angular modules locally and maintaining a parallel patch stream is a nightmare scenario that isn't acceptable, when the bug is with Protractor and $timeout, not outside modules. Please let's work together on this. |
+1 |
This bug is creating problems to have e2e test for below sample scenario,
So when we are trying to automate the scenario, we are able to submit the form. But when we are trying to click the status message link, we need to have browser.ignoreSynchronization = true; because link is attached to $timeout. The link is clickable, but a message opening as a pop up is not working. When i checked in Stackoverflow and some google answers, i got to know that it is because of the $timeout. So i checked by removing $timeout for element, now it works properly. So my request is everytime we cant have a element without $timeout. So please consider the above scenario and have a new feature where protractor can ignore waiting for $timeout. |
Faced same issue, had to use window.setTimeout and window.clearTimeout to avoid it. Not very angular way and may interfere with digest, but $interval and ignoring synchronization is not a solution |
Faced exact the same issue, will anyone from protractor team respond to this? |
+1 |
This was driving me crazy (Protractor noob here) until I arrived at a dirty solution as below:
Works fine and is not too slow on a headless browser. |
+1 |
Also running into an issue here. My tests were going smoothly until visiting a page that makes a few API requests & opens some WebSockets. At that point, Protractor times out, every time. I haven't figured out a good solution. I'm curious @floribon about your suggested helper methods if you turn off describe('something', function() {
it('should do....', function() {
var fooPage = new FooPage();
fooPage.visit();
var barPage = fooPage.clickCreate(); // does some API call, then redirects to barPage
// at this point, enough things are happening that it is impossible to interact with barPage.
// Protractor locks up.
// barPage makes other API call & opens WebSocket
barPage.clickBaz(); // nope. will timeout every time.
});
}); |
@benjaminapetersen my helpers look like this: btn1.click(); // Triggers many things and eventually displays page2
wait.forURL('page2'); // wait for page2 to be loaded before moving on
$('.btn1').click(); // this does some async job and eventually displays btn2
wait.forElement('.btn2');
$('.btn2').click(); With for instance browser.wait(() => elem.isPresent().then(p => p, () => {}), timeout, 'Not found');
// browser.wait(function() { return elem.isPresent().then(function(p) { return p;} , function() {}); }, timeout, 'Not found'); The idea is to mimic actual user behavior: I click on an element, I wait until another one is visible, then I click on it, etc. This way no need to wait for $timeout, it's faster and safer. The key here is to ignore errors from the inner promise and give it a few more tries until timeout is reached. PS: You can also use ExpectedConditions for that but I had a few problems with them when angular would rebuild the DOM node (for instance
|
@floribon awesome, thanks! |
@juliemr can u help me please me to catch the toast error messages in protractor.Pls reply on my mail id [email protected] |
@juliemr Using $interval service to invoke long running http requests is not working. Protractor still getting timeout. |
+1, something should be added to handle this. |
+1 |
5 similar comments
+1 |
+1 |
+1 |
+1 |
+1 |
This spec worked for me. Big thanks! and cheers go out to @floribon for the hint that the execution is asynchronous.
|
guys how i can add timeout for a certain test case
|
In our app we display "popup" messages to our user when certain buttons are clicked. These popup messages are only visible for about 20 seconds (after which $timeout removes them).
The problem is that Protractor seems to wait until the $timeout is completed before it .findElement() and .expect()s things. However, when the $timeout is timed out, the message is gone, and the element is not found.
Any suggestion on how to bypass/solve this? (We need to assert that the correct "popup" message is displayed to the user)
Thanks
The text was updated successfully, but these errors were encountered: