Protractor Promise Never Resolved During Debugging - protractor

I've started my Protractor debugging session with: node --inspect-brk
When I hit a break point I want to be able to manually execute some Protractor commands. However my promises are never resolved. For example if I enter this into the Chrome console:
$('body').isDisplayed().then((displayed) => {console.log('here i am'});
However all I get returned back is "Promise is Pending" and the promise is never resolved.
Any idea what I'm doing wrong?

I got round this with control flow by attaching a breakpoint to the code i want to jump to, in this case the console.log and continuing to it

you are not actually resolving the promise, and don't need the argument either. Try this:
$('body').isDisplayed()
.then(function(){
return console.log('here i am');
});

Related

How to Troubleshoot Dexie bound on IDBKeyRange Error

I'm using Dexie.js version 3.0.3-rc.3 in a Vue JS project and I occasionally run into this exception in Chrome (86):
Failed to execute 'bound' on 'IDBKeyRange': The parameter is not a valid key.↵ DataError: Failed to execute 'bound' on 'IDBKeyRange': The parameter is not a valid key.
Here's a screenshot of the full error:
I'm fairly certain the problem lies with something in my data being undefined, but I'm trying to find a good way to troubleshoot this. I paused the Chrome dev tools on exceptions and inspected the code around this particular part of Dexie, but it doesn't reveal what data was used to make this exception occur.
Does anyone have any suggestions on how to find out what's actually wrong? It feels a bit like a needle in a haystack.
== Update ==
Below is the full call stack:
Try inspecting the call stack. I know it can be long until you reach a frame within your application code, but the failing call should be there!

provideDebugConfigurations not getting called

I am using the vscode-mock-debug git as the basis for my work.
Activation event is OnDebug, although same result
I implement provideDebugConfigurations in my DebugConfigurationProvider and its not getting called.
provideDebugConfigurations(folder: WorkspaceFolder | undefined, token?: CancellationToken): DebugConfiguration[] {
return [...my data in here];
}
the resolveDebugConfiguration (the original from mock-debug) is called, I can set a breakpoint. However the provideDebugConfigurations is never getting reached. build 1.36 of vsce. am I missing something obvious ?
this is the answer from the vscode team: https://github.com/microsoft/vscode/issues/78362
I have investigated this and it is expected behavior.
Namely, provideDebugConfigurations is only called then the debug configurations are needed to generate a launch.jsonfile. If you click on the configure command the provideDebugConfigurations will get nicely called.
However if you do not have a launch.json and you simply press Debug Start, vscode will try to start debugging without using debug configurations, but using one on the fly provided by the resolveDebugConfiguration call.
More about this can be found in our docs https://code.visualstudio.com/api/extension-guides/debugger-extension
Thus closing this as designed.

How to make Protractor's browser.wait() more verbose?

In Protractor tests I call many times browser.wait method for example to wait once the particular element will appear on the screen or it will be clickable.
In many cases tests passes on my local machine, but does not on other.
I receive very generic information about the timeout which doesn't help me a lot to debug / find a source of issue.
Is it possible to make a browser.wait more verbose, for example:
if at least defaultTimeoutInterval will elapse when waiting for particular element, will it be possible to console.log information about the element that it tried to wait for,
take a screenshot when the timeout error occurs,
provide full call stack when timeout appears in browser.wait
If the main issue is that you don't know for which element the wait timed out, I would suggest writing a helper function for wait and use it instead of wait, something like:
wait = function(variable, variableName,waitingTime){
console.log('Waiting for ' + variableName);
browser.wait(protractor.ExpectedConditions.elementToBeClickable(variablename),waitingTime);
console.log('Success');
}
Because protractor stops executing test after first fail, if wait timed out, console won't print success message after failing to load a certain element.
For screenshots I suggest trying out protractor-jasmine2-screenshot-reporter, it generates an easily readable html report with screenshots and debug information on failed tests (for example, in which code line the failure occured).
Look into using protractor's Expected Condition, you can specify what to wait for and how long to wait for it.
For screenshots there are npm modules out there that can take a screenshot when a test fails. This might help.
browser.wait returns a promise, so catch the error and print/throw something meaningful like:
await browser.wait(ExpectedConditions.visibilityOf(css), waitingTime).catch((error) =>
{
throw new CustomError(`Could not find ${css} ${error.message}`)
});

How to stop automatically closing browser when writing protractor test cases

I am new to writing test cases using protractor for non angular application. I wrote a sample test case.Here the browser closes automatically after running test case.How can I prevent this. Here is my code
var submitBtnElm = $('input[data-behavior=saveContribution]');
it('Should Search', function() {
browser.driver.get('http://localhost/enrollments/osda1.html');
browser.driver.findElement(by.id('contributePercentValue')).sendKeys(50);
submitBtnElm.click().then(function() {
});
});
I was also struggling with a similar issue where i had a test case flow where we were interacting with multiple application and when using Protractor the browser was closing after executing one conf.js file. Now when I looked into the previous response it was like adding delay which depends on how quick your next action i performed or it was hit or miss case. Even if we think from debugging perspective most of the user would be performing overnight runs and they would want to have browser active for couple of hours before they analyze the issue. So I started looking into the protractor base code and came across a generic solution which can circumvent this issue, independent of any browser. Currently the solution is specific to requirement that browser should not close after one conf.js file is executed, then could be improved if someone could add a config parameter asking the user whether they want to close the browser after their run.
The browser could be reused for future conf.js file run by using tag --seleniumSessionId in command line.
Solution:
Go to ..\AppData\Roaming\npm\node_modules\protractor\built where your
protractor is installed.
Open driverProvider.js file and go to function quitDriver
Replace return driver.quit() by return 0
As far as my current usage there seems to be no side effect of the code change, will update if I came across any other issue due to this change. Snapshot of code snippet below.
Thanks
Gleeson
Snapshot of code snippet:
Add browser.pause() at the end of your it function. Within the function itself.
I found Gleeson's solution is working, and that really helped me. The solution was...
Go to %APPDATA%Roaming\npm\node_modules\protractor\built\driverProviders\
Find driverProviders.js
Open it in notepad or any other text editor
Find and Replace return driver.Quit() to return 0
Save the file
Restart your tests after that.
I am using
node v8.12.0
npm v6.4.1
protractor v5.4.1
This solution will work, only if you installed npm or protractor globally; if you have installed your npm or protractor locally (in your folder) then, you have to go to your local protractor folder and do the same.
I suggest you to use browser.driver.sleep(500); before your click operation.
See this.
browser.driver.sleep(500);
element(by.css('your button')).click();
browser.driver.sleep(500);
Add a callback function in It block and the browser window doesn't close until you call it.
So perform the action that you need and place the callback at your convenience
var submitBtnElm = $('input[data-behavior=saveContribution]');
it('Should Search', function(callback) {
browser.driver.get('http://localhost/enrollments/osda1.html');
browser.driver.findElement(by.id('contributePercentValue')).sendKeys(50);
submitBtnElm.click().then(function() {
// Have all the logic you need
// Then invoke callback
callback();
});
});
The best way to make browser NOT to close for some time, Use browser.wait(). Inside the wait function write logic for checking either visibilityOf() or invisibilityOf() of an element, which is not visible or it will take time to become invisible on UI. In this case wait() keep on checking the logic until either condition met or timeout reached. You can increase the timeout if you want browser visible more time.
var EC=protractor.ExpectedConditions;
var submitBtnElm = $('input[data-behavior=saveContribution]');
it('Should Search', function() {
browser.driver.get('http://localhost/enrollments/osda1.html');
browser.driver.findElement(by.id('contributePercentValue')).sendKeys(50);
submitBtnElm.click().then(function() {
browser.wait(function(){
EC.invisibilityOf(submitBtnElm).call().then(function(isPresent){
if(isPresent){
return true;
}
});
},20000,'error message');
});
});
I'm sure there is a change triggered on your page by the button click. It might be something as subtle as a class change on an element or as obvious as a <p></p> element with the text "Saved" displayed. What I would do is, after the test, explicitly wait for this change.
[...]
return protractor.browser.wait(function() {
return element(by.cssContainingText('p', 'Saved')).isPresent();
}, 10000);
You could add such a wait mechanism to the afterEach() method of your spec file, so that your tests are separated even without the Protractor Angular implicit waits.
var submitBtnElm = $('input[data-behavior=saveContribution]');
it('Should Search', function() {
browser.driver.get('http://localhost/enrollments/osda1.html');
browser.driver.findElement(by.id('contributePercentValue')).sendKeys(50);
submitBtnElm.click().then(function() {
});
browser.pause(); // it should leave browser alive after test
});
browser.pause() should leave browser alive until you let it go.
#Edit Another approach is to set browser.ignoreSynchronization = true before browser.get(...). Protractor wouldn't wait for Angular loaded and you could use usual element(...) syntax.
Protractor will close browsers, that it created, so an approach that I am using is to start the browser via the webdriver-reuse-session npm package.
DISCLAIMER: I am the author of this package
It is a new package, so let me know if it solves your problem. I am using it with great success.

protractor what does the timeout in expected conditions stand for?

Protractor: Version 1.8.0
browser.wait(EC.presenceOf(element), 3000);
what exactly does the 3 seconds stand for? and is there an error thrown when 3 seconds have passed and element cannot be found? or does the test just continue?
I ran a test with:
element(by.id('#input')).sendKeys('foo');
browser.wait(EC.presenceOf(element(by.xpath(BAD-LOCATOR)), 3000));
element(by.id('#input')).sendKeys('bar');
BAD-LOCATOR is just a xpath referencing a element that doesn't exists. but upon evaluating this line, the test waits beyond this time until it hits the jasmine defaultTimeoutInterval timeout (I set for 25sec). Why does it not fail in 3 secs since the promise did not get resolved in 3secs? I'm expecting the wait() to fail and the 2nd sendKeys command to execute since its next in control flow.
So the above block of code will print 'foo' into the textbox and on the next command wait until the jasmine timeout to error out (Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL.). I'm expecting an error within 3secs. 'bar'never gets printed.
It's the time out, i mean after 3 seconds if the element isn't present until now it will time out.
For the jasmine error you are getting i suggest that you add the call back
describe("long asynchronous specs", function() {
beforeEach(function(done) {
done();
}, 1000);
You can also refer to Jasmine Asynchronous Support