So it's 1 pm on a Friday and your team wants to push out a feature or bug fix ASAP. However, your test automation takes on average 6 hours to complete. You're stuck
waiting until those 6 hours are complete! This is an unfortunate circumstance I have found myself in many times. It's even more disheartening when the test run stalls midway leaving you with much wasted time and effort!
I find it fascinating that an automation test suite can be heavily built from the ground up, but there is often not much priority in optimizing those tests according to one of our most precious assets: time. More test cases are better, of course. But we must ask the pivotal question: will it scale?
That's why I think its so important to decide early on in a testing framework whether or not you will support test parallelization. If the tests cannot be parallelized, you are going to be stuck waiting many hours (and that compounds over time!) when the tests
could have been written to save time. I highly recommend encouraging your test automation to write code that is parallelizable; every test case should be as isolated as much as possible without dependence or interference of other tests. But as a DevOps engineer, you should also make sure that the framework you build upon supports it!
I wrote a blog post about
Cypress and some
examples of integrating into your own CI/CD. Another amazing fact about Cypress is that it is parallelizable right
out of the box. Assuming that your tests are independent, you can easily utilize Cypress's Dashboard which can load balance tests in queue according to a set number of available nodes. You can save an incredible amount of time by taking advantage of this feature and also get a lot of the perks that come with Dashboard (test status, test status, flaky test detection, etc).
Here at Aspera, we have even successfully managed to parallelize tests without Dashboard. In fact, our suite in serial takes about 6 hours, but managed to cut down that time to 3 hours with parallelization. This could be optimized even more but now we are able to run subsets of tests rather than the whole suite quite readily. We simply have a suite of one-liner scripts that run cypress under various conditions. You can easily split up groups of spec files to run according to filename with a glob pattern.
npx cypress run --spec cypresss/integration/subsetA/**/*-spec.js
So there you have it! Just some tips and tricks to start you off in your journey of improving test cycles and understanding the capabilities of Cypress!
Cheers!
#Aspera#continuousintegration#continuoustesting#cypress#whatsnew