Suggestions for parallelizing large chefspec runs

[swimfrog]

I have a large-and-growing set of chef cookbooks that I unit test with chefspec. Running the tests takes upward of 10 minutes on my beefy build box, and longer on a workstation, so it's no longer ideal to run the entire suite for CI, and the problem is only going to get worse. I find that I can reduce this to about 4 minutes if I parallelize the tests using a somewhat janky setup in Jenkins that calls every *_spec.rb file individually in paralllel, but this has a couple of drawbacks:

• Jenkins output looks horrible, with each test generating a pipeline step that might be retried, and the console output is hard to follow.
• The coverage report is hopelessly broken, since it breaks up the result into too many pieces.

Is there a guide, or does anyone have any recommendations for parallelizing chefspec runs in an elegant way that can make the coverage report work and return the result of unit testing all cookbooks in a single step?

[coderanger]

I've not yet found a need to parallelize and I probably run more hours of ChefSpec tests than anyone else on the planet. The key is to optimize your tests, notably use SoloRunner instead of ServerRunner as the latter is still slower (though by less than it used to be). Also remove the berks integration and handle that yourself with something faster (I use something tied in to my Halite tool chain but that probably won't work for you), and then make sure you stub everything slow. Don't use the in-memory fake data for nodes and whatnot (which doesn't work with SoloRunner anyway), use actual rspec-mocks stubs. I don't think I have a unit suite that takes more than 60 seconds to run for any cookbook so all that together should get you going.

[lamont-granquist]

I think that basically covers it. There's https://github.com/grosser/parallel_tests and https://github.com/yuku-t/parallel-rspec which might also work via more or less the same approach of splitting up the specs and running them in parallel. IDK if they solve the output problem any cleaner. Looks like they both use fork() so global in-memory state shouldn't be a problem.