click() is documented to return a promise (https://theintern.github.io/leadfoot/module-leadfoot_Command.html#click).
When I try
command
.findById("pause_button")
.click()
.then(function(){alert.isFalse(true,"OK")},
function(){alert.isFalse(true,"NOK")}
.end();
I expect either OK or NOK would be displayed. But it never occurs.
What is the reason?
Thank you.
Alain.
It's difficult to say what the issue is without seeing more of your test case. One possibility is that the command chain isn't being returned from the test. A functional test should return the command chain so that Intern knows to wait for the commands to complete.
return this.remote
.findById(...)
.click()
...
If the command chain isn't returned, Intern will assume the test has finished as soon as the test function completes, and will move on to the next test (or end the WebDriver session if there are no more tests).
Related
I get this error even when everything still right in test
Here the part of code
And someone knows how to ignore this erros?
You are calling done() before all tests have been evaluated, in fact even before you get the result for the requested URL. You need to move the done() call inside the .end callback. I would show you how if you pasted your code. But perhaps it's already clear from this description.
I write tests on CoffeeScript using Webdriver.io framework (Wdio testrunner) with sync mode enabled. According to the documentation, Webdriver.io commands should be executed in synchronous mode. However, an unexpected problem appears in the process of using the Promise.
We are considering the simplest test that finds an element on a page by selector and displays the text of the found element to the console.
Example 1 – code without promise
browser.url('... URL ...')
a = browser.$('... selector ...').getText()
console.log(a)
In this example commands of the Webdriver.io work correctly.
Example 2 - the code is in the constructor of the Promise
p = new Promise((resolve, reject) ->
browser.url('... URL ...')
a = browser.$('... selector ...').getText()
console.log(a)
resolve()
)
return p
If the commands are contained in the constructor of the Promise, then they are correctly executed too.
Example 3 - the code is in the block .then after returning the Promise
p = new Promise((resolve, reject) ->
resolve()
).then(() ->
browser.url('... URL ...')
a = $('... selector ...').getText()
console.log(a)
)
return p
The next error message shows in display: "$ (...). GetText is not a function" (Example 3). Apparently, the commands of the Webdriver.io begin to work asynchronously. Though I can use await keyword to process those Promises but I want to execute the code equally in the same way (synchronously) regardless of the location of the code (in the Promise or outside it).
Also switching to asynchronous mode occurs when command Await is used.
Example 4 (Example 1 code using the await keyword)
await console.log('123')
browser.url('... URL ...')
a = browser.$('... selector ...').getText()
console.log(a)
In this case for the correctly work of program it will be necessary to redo all the code, taking into account asynchronous processing.
As a solution, I can write all the tests asynchronously, but the code will become more complicated. Can I work with commands of the Webdriver.io synchronously even when using the Promise?
If you want to use Promise in your wdio test script which in sync mode, then you need to use browser.call() of wdio. More details on call: v5 and v4 .
Here you can find the sample code and more details on how a call is used: How to use 3rd party method that takes callback in webdriverio
Thanks,
Naveen
please explain difference between done() method and done keyword passed as a parameter to a function?
it("qwerty",function(done){
------
------
done();
});
it('qwerty', function(done){
----------
----------
.expect(404, done);
})
Please explain the differences and how many times i can call done() in loop
if i am calling like 15 times i am getting an error "multiple times done() called"
In the first example, you call it explicitly. In the second one, you pass done function as a callback to expect. It checks the response status (I assume you use supertest library) and if it equals to 404, calls done function without parameter (no error). Otherwise it calls done with something like an instance of assertation error, so mocha knows that this is a failed test.
As a regular callback, done is not supposed to be called multiple times. It should be called only once, denoting the end of some action, the test in your case. If you are looking for the ability to fail the test, just throw it.
How do I force a Mochajs test to end completely without continuing on to the next tests. A scenario could be prevent any further tests if the environment was accidentally set to production and I need to prevent the tests from continuing.
I've tried throwing Errors but those don't stop the entire test because it's running asynchronously.
The kind of "test" you are talking about --- namely checking whether the environment is properly set for the test suite to run --- should be done in a before hook. (Or perhaps in a beforeEach hook but before seems more appropriate to do what you are describing.)
However, it would be better to use this before hook to set an isolated environment to run your test suite with. It would take the form:
describe("suite", function () {
before(function () {
// Set the environment for testing here.
// e.g. Connect to a test database, etc.
});
it("blah", ...
});
If there is some overriding reason that makes it so that you cannot create a test environment with a hook and you must perform a check instead you could do it like this:
describe("suite", function () {
before(function () {
if (production_environment)
throw new Error("production environment! Aborting!");
});
it("blah", ...
});
A failure in the before hook will prevent the execution of any callbacks given to it. At most, Mocha will perform the after hook (if you specify one) to perform cleanup after the failure.
Note that whether the before hook is asynchronous or not does not matter. (Nor does it matter whether your tests are asynchronous.) If you write it correctly (and call done when you are done, if it is asynchronous), Mocha will detect that an error occurred in the hook and won't execute tests.
And the fact that Mocha continues testing after you have a failure in a test (in a callback to it) is not dependent on whether the tests are asynchronous. Mocha does not interpret a failure of a test as a reason to stop the whole suite. It will continue trying to execute tests even if an earlier test has failed. (As I said above, a failure in a hook is a different matter.)
I generally agree with Glen, but since you have a decent use case, you should be able to trigger node to exit with the process.exit() command. See http://nodejs.org/api/process.html#process_process_exit_code. You can use it like so:
process.exit(1);
As of the mocha documentation, you can add --exit flag when you are executing the tests.
It will stop the execution whenever all the tests have been executed successfully or not.
ex:
mocha **/*.spec.js --exit
Consider:
node -e "setTimeout(function() {console.log('abc'); }, 2000);"
This will actually wait for the timeout to fire before the program exits.
I am basically wondering if this means that node is intended to wait for all timeouts to complete before quitting.
Here is my situation. My client has a node.js server he's gonna run from Windows with a Shortcut icon. If the node app encounters an exceptional condition, it will typically instantly exit, not leaving enough time to see in the console what the error was, and this is bad.
My approach is to wrap the entire program with a try catch, so now it looks like this: try { (function () { ... })(); } catch (e) { console.log("EXCEPTION CAUGHT:", e); }, but of course this will also cause the program to immediately exit.
So at this point I want to leave about 10 seconds for the user to take a peek or screenshot of the exception before it quits.
I figure I should just use blocking sleep() through the npm module, but I discovered in testing that setting a timeout also seems to work. (i.e. why bother with a module if something builtin works?) I guess the significance of this isn't big, but I'm just curious about whether it is specified somewhere that node will actually wait for all timeouts to complete before quitting, so that I can feel safe doing this.
In general, node will wait for all timeouts to fire before quitting normally. Calling process.exit() will exit before the timeouts.
The details are part of libuv, but the documentation makes a vague comment about it:
http://nodejs.org/api/all.html#all_ref
you can call ref() to explicitly request the timer hold the program open
Putting all of the facts together, setTimeout by default is designed to hold the event loop open (so if that's the only thing pending, the program will wait). You can programmatically disable or re-enable the behavior.
Late answer, but a definite yes - Nodejs will wait around for setTimeout to finish - see this documentation. Coincidentally, there is also a way to not wait around for setTimeout, and that is by calling unref on the object returned from setTimeout or setInterval.
To summarize: if you want Nodejs to wait until the timeout has been called, there's nothing you need to do. If you want Nodejs to not wait for a particular timeout, call unref on it.
If node didn't wait for all setTimeout or setInterval calls to complete, you wouldn't be able to use them in simple scripts.
Once you tell node to listen for an event, as with the setTimeout or some async I/O call, the event loop will loop until it is told to exit.
Rather than wrap everything in a try/catch you can bind an event listener to process just as the example in the docs:
process.on('uncaughtException', function(err) {
console.log('Caught exception: ' + err);
});
setTimeout(function() {
console.log('This will still run.');
}, 500);
// Intentionally cause an exception, but don't catch it.
nonexistentFunc();
console.log('This will not run.');
In the uncaughtException event, you can then add a setTimeout to exit after 10 seconds:
process.on('uncaughtException', function(err) {
console.log('Caught exception: ' + err);
setTimeout(function(){ process.exit(1); }, 10000);
});
If this exception is something you can recover from, you may want to look at domains: http://nodejs.org/api/domain.html
edit:
There may actually be another issue at hand: your client application doesn't do enough (or any?) logging. You can use log4js-node to write to a temp file or some application-specific location.
Easy way Solution:
Make a batch (.bat) file that starts nodejs
make a shortcut out of it
Why this is best. This way you client would run nodejs in command line. And even if nodejs program returns nothing would happen to command line.
Making bat file:
Make a text file
put START cmd.exe /k "node abc.js"
Save it
Rename It to abc.bat
make a shortcut or whatever.
Opening it will Open CommandLine and run nodejs file.
using settimeout for this is a bad idea.
The odd ones out are when you call process.exit() or there's an uncaught exception, as pointed out by Jim Schubert. Other than that, node will wait for the timeout to complete.
Node does remember timers, but only if it can keep track of them. At least that is my experience.
If you use setTimeout in an arrow / anonymous function I would recommend to keep track of your timers in an array, like:
=> {
timers.push(setTimeout(doThisLater, 2000));
}
and make sure let timers = []; isn't set in a method that will vanish, so i.e. globally.