You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using Mocha all over the place these days and I love it. However, I often find myself parallelizing test runs. For example, I often have to spin up the same test suite multiple times for use with Sauce Labs cloud testing on multiple platforms. The only way to do this currently is to spin up child processes and load up those processes with different environment variables, telling the test suite which platform and browser to fire up when talking to Sauce Labs.
Here's an example of this happening in a gulpfile:
This configuration works great for running local selenium tests as well as cloud selenium tests on Sauce Labs. It's just cumbersome and far more low-level than I'd like. Simple things become complicated, such as formatting the test output and preserving colors. You'll note above that I have to pass in both the --color and --colors flags to the child processes to force mocha and selenium to preserve their colors; otherwise they think they are not running in a TTY-enabled terminal. Similarly I have to pipe the streamed output into a custom transform stream so I can format things appropriately. I'd still have to do this to a degree even with a programmatic mocha but it would be much simpler and far more readable. It took a lot of poking and prodding to finally arrive at a solution that worked well and printed clean readable output.
I'm writing so much code like this that I thought maybe it's time to crack open the Mocha source and start working on a programmatic API. The ability to drive mocha programmatically would be a huge help for these kinds of scenarios. Instead of spawning child processes to drive the CLI interface, I could just create mocha instances right inside of gulp and pass in options.
Before I dedicate time to this I first want to make sure it's something that would be welcomed by the project maintainers. What do you guys think? Does this just not exist because nobody has taken the time to do it, or are there other reasons to oppose such a change? I welcome the feedback :)
The text was updated successfully, but these errors were encountered:
I'm happy to hear suggestions about how this would be implemented. I was going to do it myself, but I have had higher priorities. I'm also a little hesitant to develop it in a silo. So, if you'd like to collaborate, maybe that would help me get off my ass. 😄
I'm using Mocha all over the place these days and I love it. However, I often find myself parallelizing test runs. For example, I often have to spin up the same test suite multiple times for use with Sauce Labs cloud testing on multiple platforms. The only way to do this currently is to spin up child processes and load up those processes with different environment variables, telling the test suite which platform and browser to fire up when talking to Sauce Labs.
Here's an example of this happening in a gulpfile:
This configuration works great for running local selenium tests as well as cloud selenium tests on Sauce Labs. It's just cumbersome and far more low-level than I'd like. Simple things become complicated, such as formatting the test output and preserving colors. You'll note above that I have to pass in both the
--color
and--colors
flags to the child processes to force mocha and selenium to preserve their colors; otherwise they think they are not running in a TTY-enabled terminal. Similarly I have to pipe the streamed output into a custom transform stream so I can format things appropriately. I'd still have to do this to a degree even with a programmatic mocha but it would be much simpler and far more readable. It took a lot of poking and prodding to finally arrive at a solution that worked well and printed clean readable output.I'm writing so much code like this that I thought maybe it's time to crack open the Mocha source and start working on a programmatic API. The ability to drive mocha programmatically would be a huge help for these kinds of scenarios. Instead of spawning child processes to drive the CLI interface, I could just create mocha instances right inside of gulp and pass in options.
Before I dedicate time to this I first want to make sure it's something that would be welcomed by the project maintainers. What do you guys think? Does this just not exist because nobody has taken the time to do it, or are there other reasons to oppose such a change? I welcome the feedback :)
The text was updated successfully, but these errors were encountered: