bytechefhq / bytechefhq/bytechef
Playwright property tests fail on ambiguous array delete locator and racy login
- Dominant language
- Java
- Stars
- 1k
- Forks
- 170
- Avg merge
- 11h 25m
- Merged PRs (30d)
- 115
Description
## Problem
A local Playwright run (120 tests) had 9 failures, from two causes:
### 1. Array item delete button locator is ambiguous (6 tests)
`arrayProperty.spec.ts` › *Delete array item* clicks `arrayPropertyItemAt(i).getByRole('button')`. Once a property row renders a second button (the per-property **Ask copilot** button from `PropertyCopilotButton`), the locator resolves to 2 elements and fails Playwright's strict mode:
```
strict mode violation: ...getByLabel('Array property item at index 0').getByRole('button') resolved to 2 elements:
1) aria-label="Ask copilot"
2) aria-label="Delete value.Array[0]"
```
The INTEGER-row test only passed because it used `.last()`.
### 2. Login helper is racy (3 tests, timing dependent)
`utils/login.ts` fills email and password once, clicks *Log in* and waits for navigation. Under load the login form can remount between/after the fills, wiping the typed values; the submit then fails client-side validation (`Email is required`) and `page.waitForURL` times out. Failure snapshots show the password filled but the email empty, and in another run both empty.
Affected: `propertyValidation.spec.ts` (Number Min Value, Number max decimal places), `propertyPersistence.spec.ts` (DATE_TIME).
## Fix
- Add `WorkflowPage.arrayPropertyItemDeleteButtonAt(index)` locating the delete button by its accessible name (`Delete …`) and use it for every delete click.
- Make `login()` refill, verify the values stuck and resubmit until it leaves `/login`; match the `Email`/`Password` labels exactly so the *Show Password* toggle is not matched.
Contributor guide
Assessment
This issue has not been assessed yet.