Joining efforts

[DanielMSchmidt]

For earlier discussions please see jestjs/jest#5706.

For me, the plus point of the binary was that I could use all the options we already configured and pass them to the runner directly. I thought this would make the migration easier, but I think using the node API gives us more power over what is happening.

[lgandecki]

Hello @DanielMSchmidt :-)

About the binary/api.. yeah. I'm not sure either way. Starting up with API is slow.. I'm guessing is the same with binary.
I think we need a way to reuse existing cypress session. I can imagine doing some hacks (make a temporary file to which we write all tests that have to run, with some defer.. and then run them together once the list stops growing. but that's really working around how the jest is supposed to run tests.
The other option would be to somehow have cypress detect whether there is an instance running - if there is, use that, if not, start up a new one and use that. Not sure if we can do that without quite extensive cypress modifications though.
Preferably, for the development mode, I would actually like to see th tests run in visual mode (and rerun them whenever I change my application code)
We've done that with chimp, when meteor app restarted - watched tests restarted as well, that was a fantastic dev experience.

Those are the areas are mostly concerned about currently.
What are your thoughts, goals, plans? :)

[DanielMSchmidt]

Yes, both ways start the runner pretty slowly. I think reusing the runner makes sense in some cases, for us it doesn't on CI. (Our CI RAM limit is not big enough to run every test case with the same cypress instance, we need to "force" a shutdown to allow the chromium instance to release the memory)

I would like to make it configurable that we have re-runs per test case. Integration tests can be flaky so let's take this into account 🙈

I would love to start it in visual mode, I think that would be a really nice thing