testcafe: Snapshot property warnings work incorrectly with loops

What is your Test Scenario?

Assert an unawaited snapshot property multiple times in a loop.

What is the Current behavior?

The warning is raised as if the snapshot was awaited.

What is the Expected behavior?

TestCafe should not raise warnings and the test should pass correctly.

Your complete test code (or attach your test files):

import { Selector } from 'testcafe';
fixture `Loop`;
test.only("looped assertion warning test", async t => {
    for (let i = 0; i < 2; i++) {
        await t
            .expect(Selector('body').innerText).ok();
    }
});

Your complete test report:

Running tests in:
 - Chrome 84.0.4147.105 / Windows 10

 Loop
 √ looped assertion warning test


 1 passed (1s)

 Warnings (1):
 --
  You passed a DOM snapshot property to the assertion's 't.expect()' method. The property value is assigned when the snapshot is resolved and this value is no longer updated. To ensure that the assertion verifies an
  up-to-date value, pass the selector property without 'await'.

     1 |import { Selector } from 'testcafe';
     2 |fixture `Loop`;
     3 |test.only("looped assertion warning test", async t => {
     4 |    for (let i = 0; i < 2; i++) {
     5 |        await t
   > 6 |            .expect(Selector('body').innerText).ok();
     7 |    }
     8 |});

     at <anonymous> (D:\Work\tests\expectTest\loop-test.js:6:21)
     at <anonymous> (D:\Work\tests\expectTest\loop-test.js:3:1)

Your Environment details:

testcafe version: 1.9.0-rc.1
node.js version: v12.16.1
command-line arguments: npx testcafe chrome .\loop-test.js
browser name and version: Chrome 84.0.4147.105
platform and version: Windows

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 8
Comments: 18 (9 by maintainers)

Most upvoted comments

@omartaghlabi, There is currently no option to disable these warnings. We’ll look into ways to fix the incorrectly raised warning messages in the nearest future so that a workaround will not be necessary. We’ll update this thread once the issue is fixed. Thank you for your patience.

Ogurecher on Aug 26, 2020

@GrahamLea

Hello,

We are working on the next release version. At the moment, I cannot give you any ETA. However, you can run your tests using our current release candidate version: npm i testcafe@1.9.5-rc.1.

Farfurix on Nov 3, 2020

I’m also running into this issue which is making the test logs longer than I’d like them to be. Is there a way to disable warnings? I couldn’t find documentation on this.

omartaghlabi on Aug 25, 2020

For the team: This issue is caused by the same reason as #5449.

When the snapshot property promise is resolved, its callsite is saved to a callsite storage. We check this storage in the .expect assertion call. If the storage contains a callsite with the same filename and lineNumber as the .expect’s callsite, we delete it and raise a warning.

If the property was not awaited, the .expect would execute before the property promise’s .then method. Thus, some callsites would remain in the storage after they were asserted (we delete them only in .expect). It works fine if we use our assertion only once, but causes the warnings to raise if we call .expect from the same line of code again.

Ogurecher on Sep 28, 2020

@VladRose

Hello,

We are happy to hear that the issue is resolved with the rc version. Please note that the current release candidate version is testcafe@1.10.0-rc.5.

Farfurix on Dec 4, 2020

npm i testcafe@1.9.5-rc.1 Worked! Thanks. Waiting for new release!

await Promise.all(
  inputsKeys.map((inputName) => {
    const inputText = inputs[inputName];
    return handleInputTypeText(inputName, inputText);
  }),
);

vladrose on Dec 3, 2020

@Khartir, Thank you for the example. We’re working on a fix for the issue you outlined in the context of this issue.

Ogurecher on Sep 25, 2020