Hangs with Jest run

[dennismphil]

When I attempted to integrate this with Jest using TAIKO_PLUGIN=screencast jest it seemed to hang.

This is a very useful and powerful feature, especially during test runs headlessly.

Thank you for the hard work and the beautiful API ❤️

[shubhamsc]

@dennismphil Thanks for reporting, I can replicate this issue with this example while running with jest.

const { openBrowser, closeBrowser, goto, click, screencast, text } = require('taiko');

describe('taiko screencast', () => {
    beforeAll(async () => {
        await openBrowser();
        await screencast.startScreencast('output.gif');
    })

    afterAll(async () => {
        await screencast.stopScreencast();
        await closeBrowser();
    })

    test('test for screencast', async () => {
        await goto('gauge.org');
        await click('Plugins');
        expect(await text('Language Runners').exists()).toBeTruthy();
    });
});

Tests are hanged on stopScreencast. we will look on it soon.

[negiDharmendra]

I have tried debugging this issue and found out that it takes a lot of time to generate gif file with jest where as works fine with mocha and plain Taiko script. For the given sample script in the previous comment it takes around 3 minutes.

Could not find any reason why it takes more time with jest.

[dennismphil]

Instrumented some of the taiko code with console logs while running.

This is where it seems like stalling for me. Gave it 15 mins it still remains there.

[BugDiver]

Did some more debugging and found out that, The . GifEncoder packages tries to learn the color palate for every frame and alter them accordingly. Which is taking a lot of time with jest. Could not figure out why it take more time only with jest, work fine with mocha. Maybe we can look for alternative GifEncoders.

[librehat]

Any updates on this one please?

[sriv]

Not yet, we have been busy with other things. It might be some time till we get to this, since we have our hands full at the moment.

That said, we would appreciate any help, and would gladly accept Pull Requests!

[dennismphil]

Got a chance to debug this more. Yes, this completed after a really really really long time.

Eg: 47 frames; device height=1250; device width: 1200; => takes a long time and finally completes.

The encoder addFrame is where it takes most time. ~30s per frame.

Suggestion

Short term fix

skip few frames (eg use a logarithmic scale for i in the loop of adding frame) or limit the device width and height could be easy fixes.

Long term fix:

Consider switching to a more efficient encoder.

[sriv]

The thing with skipping frames is that the plugin has no way of telling if it's skipping an important frame.

gif-encoder-2 claims some improvements, and at first glance it looks like a drop-in replacement.

That being said, I wonder why would this bother only jest, and not other runners.

[spinningarrow]

Any reason why it emits a gif and not an m4v or something like that? My understanding is those are more compact and efficient (could be wrong though!)

[sriv]

Any reason why it emits a gif and not an m4v

gif, primarily because it is html/browser friendly. but one could argue that modern browsers allow videos to be embedded too. Perhaps we can have it configurable.

Really depends on what works best for users. We do not use this much :P

[librehat]

Any modern browsers should be able to handle video files just fine, adding the good things that you can control the progress bar and play/pause

[sriv]

Any modern browsers should be able to handle video files just fine

That is true. Anybody interested in taking a stab at this? I believe it shouldn't be too hard to wire up something like ffmpeg and dump the output as a movie?