Pretty new to Mocha and testing here, so hoping somebody can help me out or point me in the right direction.
What I am trying to do is have a mochaJS test run every 5 minutes for an entire day. However, I don't want to actually type the command, and am hoping that I could write some code that would carry this out.
So far, I have tried adjusting the this.timeout in the mocha test, and then setting javascript intervals (setInterval(function(){}, time)) and using while loops with the setTimeout.
Is it possible to set an interval like this in mocha?
Or is there some other way around this, say through command line, that would execute the mocha test every 5 minutes?
Thank you for your advice and expertise!
Cheers
This really sounds like a task that should be managed by a Continuous Integration server such as Jenkins.
If you install Jenkins, you can create a new job that will run the tests you want on a given interval, ie. every 5 minutes. Better yet, you can connect the Job to your source code repo and run the job on any code push.
Related
in my Jest test suite,
i use
jest.retryTimes(4)
because of the particular and instable architecture of the software. And this works as expected.
There are some test that must to pass at the first time so for these particular test i need to set
jest.retryTimes(1)
at the beginning of the test, restoring
jest.retryTimes(4)
at the end.
There are two problems :
The problem is this configuration is global, and test are executed
in parallel, so when this test start, it put 1 to jest retry for all
the test running at this moment. I would like to make only this
particular test fail the first time.
Jest Circus ignore the update of jest.retryTimes at the beginning and at the end
of the test, it keep considering 4 temptative before of raise the failure.
I read the documentation but I think I cannot obtain this result.
any suggestion?
Thanks
we are using codeceptjs for e2e tests for my work. For every code submission, we run these tests (we use webpack-dev-server to mock the backend).
In the beginning, the time spent to run these tests is acceptable. However after 1 year we have around 900 tests (i.e. CodeCept's Scenarios) and it takes around 1 hour to finish. Basically after finishing a feature we add some tests and for bugs we also add e2e test. We realize this is not sustainable if we keep adding more e2e tests since it takes to long to run. Do you have any suggestions how can I improve them ( we are using codeceptjs ) ?
I am thinking about only running some e2e tests for important features for each submission, the rests should be run separately ( maybe once per day ). Thanks.
I am trying to understand how node-cron by kelektiv works.
Specifically, if your node app crashes, how does it remember the dates that you scheduled for an event? Does it store the jobs in a database somewhere or a somewhere locally on the machine?
Any recommended reading resources or an explanation will be very helpful.
Thank you in advance for your answer.
See this code: https://github.com/kelektiv/node-cron/blob/master/lib/cron.js
They are using methods to calculate when to send next by sendAt, how much time is left before sending next by getTimeout and then they are simply putting a setTimeout based on that in start.
It's a nice piece of code and I'll suggest you to check it out, it's very simple and written in very understandable way.
And no it doesn't stores the next time in Database, it's just setTimeout
We have an existing application, the tests are written in cypress. We now want to integrate a cucumber style feature which will internally run using cypress. We used cypress-cucumber-preprocessor for the same. I followed the steps given here on the github page. The problem I'm facing now, is while running tests, it shows both the scenarios, but runs only one. Shows a green tick mark next to it, but doesn't start the second one, and the clock keeps on ticking. On clicking the second scenario in the cypress launcher it says - no commands were issued in this test.
What have I tried:
I tried to duplicate the same scenario twice in the same feature file. It still runs only first one and does not move to the next one.
I moved both different scenarios in two different feature files. It runs both of them successfully.
I tried to run the example repo (cypress-cucumber-example) locally with n number of scenarios. That works seamlessly.
Some observations:
While the first test is run I ran chrome console, and saw some errors due to some network calls failing. But these calls were made (with same errors) even when I was using only cypress and hadn't integrated with cucumber, and all tests were passing. Is it because of some magic cucumber is bringing along with it? Read somewhere default cucumber waits for a test is 60 seconds, I waited for maximum 170 seconds, and then stopped the suite. At the end all I get is one scenario green and other not even started.
It took me quite a long time, but I actually figured out what the issue was. I had an enter key after Feature: in my feature file. The ide didn't raise it as any problem and all was good. I was just comparing successful runs against this issue and saw that the feature name is not appearing in the UI, and hence took away the \n. It works like a charm now. Wondering what a small enter key can do.
I'm setting up a 2 builds in Teamcity, with scheduled triggering using cron expressions.
I want the builds to alternate every other day. I.e., one gets build on one day, then the other one gets built the next day.
Under no circumstance do I want the same build to run 2 days back to back.
Is this sort of scheduling even possible using cron expressions?
This is impossible to do using only cron, but you can still get this behavior with a bit of a workaround. Create a simple script or program in whatever language you prefer that keeps track of the last build program to run. Any time it is run have it run the build that was not run last, then save that one as the new 'last build'. Then, run this program using cron every day.
You'll need to figure out what works for saving the last build in a persistent way, one the simpler approaches would be to use a file.