Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.disableConcurrency flag not respected in quarantine mode #8087

Closed
Makavelic opened this issue Nov 21, 2023 · 3 comments
Closed

.disableConcurrency flag not respected in quarantine mode #8087

Makavelic opened this issue Nov 21, 2023 · 3 comments
Assignees
Labels
TYPE: bug The described behavior is considered as wrong (bug).

Comments

@Makavelic
Copy link

Makavelic commented Nov 21, 2023

What is your Scenario?

I have a fixture with .disableConcurrency set and am running tests with -c 3 with quarantine mode on. I expect each test to run sequentially even when the test fails (to ensure each test cleans up before another starts, the actual order in which they run doesn't matter).

What is the Current behavior?

Quarantine mode ignores .disableConcurrency

What is the Expected behavior?

Quarantine mode should still respect .disableConcurrency and only one test at a time should execute.

What is the public URL of the test page? (attach your complete example)

Website not needed to demonstrate issue.

What is your TestCafe test code?

let someValue = false;

fixture("quarantineTest")
.beforeEach(async (t) => {
await t.wait(1);
someValue = false;
})
.afterEach(async (t) => {
await t.wait(1);
someValue = true;
}).disableConcurrency;

test("test1", async (t) => {
await t.wait(1000);
await t.expect(someValue).notOk("Verify value reset");
throw new Error();
});

test("test2", async (t) => {
await t.wait(1000);
await t.expect(someValue).notOk("Verify value reset");
throw new Error();
});

test("test3", async (t) => {
await t.wait(1000);
await t.expect(someValue).notOk("Verify value reset");
});

test("test4", async (t) => {
await t.wait(1000);
await t.expect(someValue).notOk("Verify value reset");
});

test("test5", async (t) => {
await t.wait(1000);
await t.expect(someValue).notOk("Verify value reset");
});

test("test6", async (t) => {
await t.wait(1000);
await t.expect(someValue).notOk("Verify value reset");
});

test("test7", async (t) => {
await t.wait(1000);
await t.expect(someValue).notOk("Verify value reset");
});

test("test8", async (t) => {
await t.wait(1000);
await t.expect(someValue).notOk("Verify value reset");
});

Your complete configuration file

Not needed

Your complete test report

See screenshots

Screenshots

Screenshot when c = 3
image

Screenshot when c = 1
image

Steps to Reproduce

Run fixture with cli:

node testcafe 'chrome:headless' 'pathToFile\quarantineTest.ts' '-c' '3' '-q' 'successThreshold=1,attemptLimit=3' '--fixture' 'quarantineTest'

Notice how tests 3-8 can be unstable

Run again with -c =1
node testcafe 'chrome:headless' 'pathToFile\quarantineTest.ts' '-c' '1' '-q' 'successThreshold=1,attemptLimit=3' '--fixture' 'quarantineTest'

Notice how there are no unstable tests. This demonstreates that quarantineMode ignores .disableConcurrency

TestCafe version

3.4.0

Node.js version

18.16.0

Command-line arguments

node testcafe 'chrome:headless' 'pathToFile\quarantineTest.ts' '-c' '3' '-q' 'successThreshold=1,attemptLimit=3' '--fixture' 'quarantineTest'

Browser name(s) and version(s)

Browser doesn't matter

Platform(s) and version(s)

Windows 11

Other

No response

@Makavelic Makavelic added the TYPE: bug The described behavior is considered as wrong (bug). label Nov 21, 2023
@need-response-app need-response-app bot added the STATE: Need response An issue that requires a response or attention from the team. label Nov 21, 2023
@PavelMor25 PavelMor25 added STATE: Issue accepted An issue has been reproduced. and removed STATE: Need response An issue that requires a response or attention from the team. labels Nov 22, 2023
Copy link

We appreciate you taking the time to share information about this issue. We reproduced the bug and added this ticket to our internal task queue. We'll update this thread once we have news.

Copy link

Release v3.5.0-rc.1 addresses this.

1 similar comment
Copy link

Release v3.5.0-rc.1 addresses this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
TYPE: bug The described behavior is considered as wrong (bug).
Projects
None yet
Development

No branches or pull requests

2 participants