Implement automated snapshot testing

[Juansasa]

What is your Test Scenario?

Generate snapshot of the testing page and compare in consecutive testing

What are you suggesting?

Jest already have well documented use cases for this type of testing methodology.

What is needed.

• Commandline support for updating snapshot
• Specialized selector to get relevant snapshot of all element values of the page.
• Snapshot file serialization and deserialization and expect extension

Something like this would be nice expect( SnapshotSelector({ "div.test_class": "textContent", "input.#test_id": "value", span: (elements: Element) => any, }), ).toMatchSnapshot();

What alternatives have you considered?

Additional context

[miherlosev]

Hi @Juansasa

Thank you for your suggestion. We've already thought about this capability and discussed these API variants:

// Extend 'contains' method

await t.expect(Selector('.button'')).contains({
    id:      'test-id',
    class: 'test-class'
});

// New 'containsProperties' method
await t.expect(Selector('.button')).containsProperties({
    id:      'test-id',
    class: 'test-class' 
});

We will update this thread once we decide on the final API structure.

[AndreyBelym]

Selector is a function that asynchronously returns a DOM Node state snapshot. Even if your Selector doesn't have parameters (actually all Selectors if you don't use a function as a constructor), it needs to be called to obtain its results (Selector('element')()). Then you can use the contains assertion to assert several properties at the same time:

import { Selector } from 'testcafe';

fixture('Simple login test')
    .page('https://example.com');

test('login', async t => {
    await t.expect(Selector('body')()).contains({
        tagName: 'body',
        visible: true
    });
});

I created a separate issue to allow retrieving state snapshots from selectors without calling: https://github.com/DevExpress/testcafe/issues/5288.

[Juansasa]

@AndreyBelym @miherlosev I'm not sure what i'm proposing is exactly what you are describing. The point of snapshot testing is not to generate a snapshot state for further assertions but to remove all assertions completely.

[LavrovArtem]

Thank you for clarifying your inquiry. Jest's snapshot testing looks like an interesting feature. We will gather some feedback and will consider adding it to our roadmap.

[miherlosev]

https://stackoverflow.com/questions/65138338/does-testcafe-support-snapshot-testing-like-jest

[pavsenin]

https://stackoverflow.com/questions/69212510/in-testcafe-can-we-declare-a-variable-in-a-testcase-and-use-the-same-as-an-expec

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had any activity for a long period. It will be closed and archived if no further activity occurs. However, we may return to this issue in the future. If it still affects you or you have any additional information regarding it, please leave a comment and we will keep it open.

[github-actions[bot]]

We're closing this issue after a prolonged period of inactivity. If it still affects you, please add a comment to this issue with up-to-date information. Thank you.

[GregorBiswanger]

@LavrovArtem What is the state for snapshot support?

[AlexKamaev]

We do not have any updates regarding this feature. Currently, we are fully focused on other tasks, such as experimental proxyless mode.

[GregorBiswanger]

@AlexKamaev What exactly is proxyless doing under the hood? Does it then use the Chrome Automation API? So why is it running faster? I am curious :)

I hope not the Chrome Automation API, where then you have to download a few MB again, like with Cypress. That's why I don't like Cypress either.

[AlexKamaev]

@GregorBiswanger We use Chrome DevTools Protocol. It's running faster because it allow us to stop using some time-demanding features of testcafe-hammerhead. See this thread for details: https://testcafe.io/documentation/404237/guides/experimental-capabilities/proxyless-mode.

[GregorBiswanger]

@AlexKamaev As long as it keeps ANY browser support and you don't need any browser-specific extra downloads, that sounds great!

[AlexKamaev]

@GregorBiswanger,

As long as it keeps ANY browser support

At present, we support Chrome-based browsers (chrome, chromium, edge).

you don't need any browser-specific extra downloads

You are right. Using Chrome DevTools Protocol does not require downloading any additional data.

[GregorBiswanger]

@AlexKamaev Proxyless for Chrome-based browsers and for the support of all browsers then with a proxy? The ANY browser support ala Safari etc. is really important not to lose this as a unique selling point.

[AlexKamaev]

@GregorBiswanger Sure, we will continue to support other browsers. I meant that the new CDP mode will be implemented only in Chromium-based browsers.