We have recently upgraded to angular 5. Since then my protractor tests started failing with reason " Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL.".
All these tests were working fine before.
Protractor version : 5.2.0
karma version: 1.7.0
Highly appreciate your suggestions.
Thanks
This is a Jasmine timeout, see the Protractor guidance on Jasmine timeouts:
Timeouts from Jasmine
Spec Timeout
If a spec (an 'it' block) takes
longer than the Jasmine timeout for any reason, it will fail.
Looks like: a failure in your test results - timeout: timed out after
30000 msec waiting for spec to complete
Default timeout: 30 seconds
How to change: To change for all specs, add jasmineNodeOpts:
{defaultTimeoutInterval: timeout_in_millis} to your Protractor
configuration file. To change for one individual spec, pass a third
parameter to it: it(description, testFn, timeout_in_millis).
Try to debug your test, instructions here. Following any change, including an upgrade, it's possible your test may be broken; resulting in it hanging beyond the duration of the default Jasmine timeout.
A lazy option would be to increase your Jasmine timeout excessively, to see if your test fails with a different exception.
Related
I have a pytest suite running in this env:
Test session starts (platform: linux, Python 3.6.1, pytest 3.3.1, pytest-sugar 0.9.1)
plugins: flaky-3.5.3, dependency-0.3.2, forked-0.2, logger-0.4.0, sugar-0.9.1, xdist-1.24.1
I have a parametrized test, decorated with flaky, and it is supposed to be re-run max three times if it fails.
#pytest.mark.flaky(max_runs=3) # re-run this test in case it fails
def test_cucubau(getBauBau_fixture):
assert cucubau(getBauBau_fixture) == True
However, it fails only once, it is not re-run, and my flaky test report is empty.
===Flaky Test Report===
===End Flaky Test Report===
Based on what I read about flaky plugin, the usage should be trivial.. but I'm not able to see what is wrong with my code.
any idea?
I believe you need the pytest-rerunfailures plugin for that to work. Then you should be able to annotate your test with #pytest.mark.flaky(reruns=3).
I have a simple monolithic application generated using JHipster v4.10.1 with front-end using Angular 4.x. To run JavaScript unit tests, as suggested in the documentation I ran
./node_modules/karma/bin/karma start src/test/javascript/karma.conf.js --debug
The command runs the tests, reports coverage summary and exits, whether tests all pass or some test fail does not matter. Test run output does show at one point that the debug server is loaded:
21 11 2017 13:41:20.616:INFO [karma]: Karma v1.7.1 server started at http://0.0.0.0:9876/
But because the command exits, the Karma debug server can not be accessed. How to run tests so that Karma console can be used in browser to debug?
Figured out that the magic flag is actually single-run which seems to be true by default. So the main command to run for JS debug is:
yarn test --single-run=false
which in turn runs
$ karma start src/test/javascript/karma.conf.js --single-run=false
With this the command will only exit with explicit kill e.g. with Ctrl+C or Z. Karma debug console can then be accessed on http://localhost:9876/debug.html (assuming default port is not already busy. If it is, test output should tell you which port was chosen).
Additionally you need to disable minimization (and also istanbul config - not sure why) so that you can breakpoint and step through the .ts code in debugger easily. I figured this is done by making following changes in webpack/webpack.test.js file:
Remove following istanbul config from module.rules array:
{
test: /src[/|\\]main[/|\\]webapp[/|\\].+\.ts$/,
enforce: 'post',
exclude: /(test|node_modules)/,
loader: 'sourcemap-istanbul-instrumenter-loader?force-sourcemap=true'
}
Add minimize: false to the LoaderOptionsPlugin under plugins array:
new LoaderOptionsPlugin({
minimize: false,
options: {
tslint: {
emitErrors: !WATCH,
failOnHint: false
}
}
})
I have a project that has been running well for a long time now.
Recently (couple of weeks) the system tests are failing.
After a lot of investigation we concluded that protractor fails to identify and close an alert.
The code that used to work
exports.removeFaq = function( index ){
console.log('deleting item at',index);
exports.getContent(index).$( '[ng-click="removeFAQ($index)"]').click();
browser.sleep(2000);
browser.switchTo().alert().accept();
return browser.sleep(2000);
};
is now throwing errors:
WebDriverError: unknown error: cannot determine loading status
from unexpected alert open
(Session info: chrome=52.0.2743.116)
(Driver info: chromedriver=2.21.371461 (633e689b520b25f3e264a2ede6b74ccc23cb636a),platform=Linux 4.2.0-38-generic x86_64) (WARNING: The server did not provide any stacktrace information)
and (using element explorer):
> browser.switchTo().alert().accept();
UnexpectedAlertOpenError: unexpected alert open: {Alert text : are you sure you want to remove this helper content?}
(Session info: chrome=52.0.2743.116)
(Driver info: chromedriver=2.21.371461 (633e689b520b25f3e264a2ede6b74ccc23cb636a),platform=Linux 4.2.0-38-generic x86_64) (WARNING: The server did not provide any stacktrace information)
We've tried
- waiting instead of sleeping.
- sleeping for a long period
- ignoring angular.
nothing seems to make any difference whatsoever.
how can I fix this?
We had the same issue for a couple of days. Looks like we were on chromedriver 2.21. I updated to the latest version (2.23) and that seems to have fixed the issue.
The command webdriver-manager update --chrome did not work for me so I had to download the zip and extract it to my selenium directory. Under protractor.
Note there is a new protractor major version with updated versions. So updating protractor might fix the problem too.
for protractor version 3.x
You can also modify the file node_modules/protractor/config.json with the correct version and then run webdriver-manager update
for protractor version 4.x
You should modify the file ./node_modules/protractor/node_modules/webdriver-manager/config.json instead.
How can we say for sure that sleep of 2000ms is good enough? Exactly for this reason sleeps are not recommended in tests. Instead you can use proper waits and poll for alert. This way you would know that after a certain agreed timeout, alert never showed up and test rightfully failed
//wait maximum up to lets 5s before giving up
browser.wait(protractor.ExpectedConditions.alertIsPresent(), 5000);
browser.switchTo().alert().accept();
After the build is completed, in the performance Trend report error column displays 100% error whereas the HTTP Response code is 200 (Successful)
Expected Result: That should be 0% error in error column.
We have performance plugin 1.13 in jenkins 1.607
My .jtl file contains:
1434631428652,2082,Deactivate_Enrollee,200,OK,setUp Thread Group 1-1,text,true,536,2073
1434631430748,574,Activate_Enrollee,200,OK,setUp Thread Group 1-1,text,true,536,574
1434631431323,315,User_Status,200,OK,setUp Thread Group 1-1,text,true,1317,315
1434631431711,1,Debug Sampler,200,OK,setUp Thread Group 1-1,text,true,807,0
Console output:
Started by user anonymous
Building in workspace /results/jtls
Performance: Percentage of errors greater or equal than 0% sets the build as unstable
Performance: Percentage of errors greater or equal than 0% sets the build as failure
Performance: Recording JMeter reports '*.jtl'
Performance: Parsing JMeter report file APITest_JMeter.jtl
Performance: File APITest_JMeter.jtl reported 100.0% of errors [FAILURE]. Build status is: FAILURE
Build step 'Publish Performance test result report' changed build result to FAILURE
Finished: FAILURE
Can anyone solve this for Jenkins?
It seems that it is due to a defect in Performance Plugin version 1.13.
You may use Performance Plugin version 1.9 or below and let us know if this resolves your issue.
Your jtl file is wrong for the plugin from :
https://github.com/jenkinsci/performance-plugin/blob/master/src/main/java/hudson/plugins/performance/JMeterCsvParser.java#L157
So this leads to failure of parsing this value to a boolean by this code:
sample.setSuccessful(Boolean.valueOf(values[successIdx]));
I think your configuration of saveservice is not well suited for the plugin, you should set:
jmeter.save.saveservice.response_message=false
I think you may be facing well-known critical bug 28426 of Performance Plugin.
I am using a Scala compilation server. This is probably not related to my IDE IntelliJ IDEA, but I will just inform you that I start the Scala compilation server through a special run configuration in that IDE.
After some time that goes by without compiling anything, the compilation server terminates, without any message. Usually, I only notice this when I try to compile something and compilation fails. Then, I need to start the compilation server again, and of course the next compilation takes a long time, because it's once more the first compilation since starting the compilation server.
How do I turn off that timeout? I looked at the manpage for scalac, and there seems to be no option for it. I can add VM options for that run configuration.
Pass -max-idle 0 as parameter. It will work on a very (very!) recent nightly, and it should be available on Scala 2.9.0 when it comes out. However, there's no guarantee the name won't change until then.
I don't think you can. Here is a code snippet from the compilation server:
object SocketServer
{
// After 30 idle minutes, politely exit.
// Should the port file disappear, and the clients
// therefore unable to contact this server instance,
// the process will just eventually terminate by itself.
val IdleTimeout = 1800000
val BufferSize = 10240
def bufferedReader(s: Socket) = new BufferedReader(new InputStreamReader(s.getInputStream()))
def bufferedOutput(s: Socket) = new BufferedOutputStream(s.getOutputStream, BufferSize)
}
I think you should open a feature request in scala-lang.org