I have only 3 test cases on a spec file -but when i run this spec -cypress runner often crashes chrome browser.
And i have to restart again.
Is this is something with my code ? or is there any solutions for this
Thanks
Try setting the numTestsKeptInMemory: 5, the default value might be 50. This way was can reduce the memory consumption. Save the configuration, close and star the app again.
Avoid writing lengthy tests and split the test file into multiple test/spec files.
Related
First of all, my terminology may be incorrect with some of these terms as I am very new to jest so if that is the case I would love to be corrected to help me learn.
In case I am using the jest terminology incorrectly, here is what I mean:
Test Suite - The entire group of test files I am attempting to run
Test File - The actual .js test file that is being run
Test - The individual 'it' code blocks in each test file.
Currently, I am using a group of around 20 jest tests to test my API EPs for my SQL Server and its corresponding linked server.
To do this, I run an npm command like so in the terminal.
npm run test:file ape/linked -- --env=monke.env
With how jest currently is working, if one of tests in the 20 test files fails, then it quits out of the test suite entirely.
I would like it to just fail out of whatever test file it is in, then continue to the next text file.
I know jest currently has the --bail flag, but enabling this continues the same test file on failure which I can't have happen due to the nature of my linked server to my actual SQL server.
Any help would be greatly appreciated and I am new to all of this so let me know if more info needs to be included.
This will be running on various mac versions as well as Ubunutu server
Each time I run my selenium script, which uses a Chrome Webdriver, I find that at the end of the execution, I have significantly (~50 Mb) less memory in my drive. I am not pulling/storing data anywhere, I am just instructing it to complete a series of clicks to navigate some UI, so why would this be happening? I suspect that is has to do with my webdrivers never actually quitting, but I'm not sure why that would be the case? If I close out of the chrome page being run by selenium prematurely, I'm assuming the driver closes too? And in the case where it does conclude running, I explicitly program the driver to quit.
Additionally, I can no longer open chrome through my desktop. It simply won't start.
Can someone give me some advice or enlighten me about what is actually taking place behind the scenes to cause this problem?
When execution starts chromedriver creates some temp directories in this location :
C:\Users\username\AppData\Local\Temp
these directories starts with name like "scoped_dir8952_11195" and every directory created by chrome in temp folder starts with "scoped_dir".
when driver.quit() or close() is called it should be deleted but if it is not getting deleted then you have to delete it after execution using java code or you can simply create a .bat file that deletes the directories starting with name "scoped_dir" and then can execute it using ProcessBuilder or Runtime.exec() .
You can also manually delete them if you want.
Hope that helps you.
When using the APIs defined by Protractor & Jasmine (the default/supported runner for Protractor), the tests will always work okay on individual developer laptops. For some reason when the test runs on the Jenkins CI server, they will fail (despite being in the same docker containers on both hosts, and that was wildly frustrating.)
This error occurs: A Jasmine spec timed out. Resetting the WebDriver Control Flow.
This error also appears: Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL.
Setting getPageTimeout & allScriptsTimeout to 30 seconds had no effect on this.
I tried changing jasmine.DEFAULT_TIMEOUT_INTERVAL to 60 seconds for all tests in this suite, once the first error appears then every test will wait the full 60 seconds and time out.
I've read and reread Protractor's page on timeouts but none of that seems relevant to this situation.
Even stranger still, it seems like some kind of buffer issue - at first the tests would always fail on a particular spec, and nothing about that spec looked wrong. While debugging I upgraded the selenium docker container from 2.53.1-beryllium to 3.4.0-einsteinium and the tests still failed but they failed a couple specs down - suggesting that maybe there was some optimization in the update and so it was able to get more done before it gave out.
I confirmed that by rearranging the order of the specs - the specs that had failed consistently before were now passing and a test that previously passed began to fail (but around the same time in the test duration as the other failures before the reorder.)
Environment:
protractor - 5.1.2
selenium/standalone-chrome-debug - 3.4.0-einsteinium
docker - 1.12.5
The solution ended up being simple - I first found it on a chrome bug report, and it turned out it was also listed right on the front page of the docker-selenium repo but the text wasn't clear as to what it was for when I'd read it the first time. (It says that selenium will crash without it, but the errors I was getting from Jasmine were just talking about timeouts, and that was quite misleading.)
Chrome apparently utilizes /dev/shm, and apparently that's fairly small in docker. There are workarounds for chrome and firefox linked from their README that explain how to resolve the issue.
I had a couple test suites fail after applying the fix but all the test suites have been running and passing for the last day, so I think that was actually the problem and that this solution works. Hope this helps!
I am running my spec flow feature files with the help of resharper and certain feature files have been ignored for later use with #ignore tag. What happens is that chromedriver opens these tests, realizes that they are ignored and stop the test. As I run the tests from a folder, it takes upto 5 mins for every folder that contain these ignored tests. Is there a way to prevent the test runner,runnning these ignored tests so that I can save some time ?
That really depends on where you are starting chromedriver from. If you are starting the driver in a [BeforeScenario] step then yes. Its as simple as this:
if(!ScenarioContext.Current.ScenarioInfo.Tags.Contains("ignore")){
//start chromedriver
}
in this way you can check to make sure if the current scenario should be ignored or not and avoid starting chromedriver if it is.
We're running tests using karma and phantomjs Last week, our tests mysteriously started crashing phantomJS with an error of -1073741819.
Based on this thread for Chutzpah it appears that code indicates a native memory failure with PhantomJS.
Upon further investigation, we are consistently seeing phantom crash around 750MB of memory.
Is there a way to configure Karma so that it does not run up against this limit? Or a way to tell it to flush phantom?
We only have around 1200 tests so far. We're about 1/4 of the way through our project, so 5000 UI tests doesn't seem out of the question.
Thanks to the StackOverflow phenomenon of posting a question and quickly discovering an answer, we solved this by adding gulp tasks. Before we were just running karma start at the command line. This spun up a single instance of phantomjs that crashed when 750MB was reached.
Now we have a gulp command for each one of our sections of tests, e.g. gulp common-tests and gulp admin-tests and gulp customer-tests
Then a single gulp karma that runs each of those groupings. This allows each gulp command to have its own instance of phantom, and therefore stay underneath that threshold.
We ran into similar issue. Your approach is interesting and certainly side steps the issue. However, be prepared to face it again later.
I've done some investigation and found the cause of memory growth (at least in our case). Turns out when you use:
beforeEach(inject(SomeActualService)){ .... }
the memory taken up by SomeActualService does not get released at the end of the describe block and if you have multiple test files where you inject the same service (or other injectable objects) more memory will be allocated for it again.
I have a couple of ideas on how to avoid this:
1. create mock objects and never use inject to get real objects unless you are in the test that tests that module. This will require writing tons of extra code.
2. Create your own tracker (for tests only) for injectable objects. That way they can be loaded only once and reused between test files.
Forgot to mention: We are using angular 1.3.2, Jasmine 2.0 and hit this problem around 1000 tests.
I was also running into this issue after about 1037 tests on Windows 10 with PhantomJS 1.9.18.
It would appear as ERROR [launcher]: PhantomJS crashed. after the RAM for the process would exceed about 800-850 MB.
There appears to be a temporary fix here:
https://github.com/gskachkov/karma-phantomjs2-launcher
https://www.npmjs.com/package/karma-phantomjs2-launcher
You install it via npm install karma-phantomjs2-launcher --save-dev
But then need to use it in karma.conf.js via
config.set({
browsers: ['PhantomJS2'],
...
});
This seems to run the same set of tests while only using between 250-550 MB RAM and without crashing.
Note that this fix works out of the box on Windows and OS X, but not Linux (PhantomJS2 binaries won't start). This affects pushes to Travis CI.
To work around this issue on Debian/Ubuntu:
sudo apt-get install libicu52 libjpeg8 libfontconfig libwebp5
This is a problem with PhantomJS. According to another source, PhantomJS only runs the garbage collector when the page is closed, and this only happens after your tests run. Other browsers work fine because their garbage collectors work as expected.
After spending a few days on the issue, we concluded that the best solution was to split tests into groups. We had grunt create a profile for each directory dynamically and created a command that runs all those profiles. For all intents and purposes, it works just the same.
We had a similar issue on linux (ubuntu), that turned out to be the amount of memory segments that the process can manage:
$ cat /proc/sys/vm/max_map_count
65530
Then run this:
$ sudo bash -c 'echo 6553000 > /proc/sys/vm/max_map_count'
Note the number was multiplied by 100.
This will change the session settings. If it solves the problem, you can set it up for all future sessions:
$ sudo bash -c 'echo vm.max_map_count = 6553000 > /etc/sysctl.d/60-max_map_count.conf'
Responding to an old question, but hopefully this helps ...
I have a build process which a CI job runs in a command line only linux box. So, it seems that PhantomJS is my only option there. I have experienced this memory issue locally on my mac, but somehow it doesn't happen on the linux box. My solution was to add another test command to my package.json to run karma using Chrome, and run that locally to run my tests. When pushed up, Jenkins would kick off the regular test command, running PhantomJS.
Install this plugin: https://github.com/karma-runner/karma-chrome-launcher
Add this to package.json
"test": "karma start",
"test:chrome": "karma start --browsers Chrome"