microsoft
[BUG] Playwright breaks in case of current directory case mismatch
Context:
- Playwright Version: 1.24.2
- Browser: All
## System:
- OS: Windows 10 10.0.19044
- Memory: 2.98 GB / 15.93 GB
## Binaries:
- Node: 16.14.0 - C:\Program Files\nodejs\node.EXE
- Yarn: 1.22.10 - ~\AppData\Roaming\npm\yarn.CMD
- npm: 8.3.1 - C:\Program Files\nodejs\npm.CMD
## Languages:
- Bash: 4.4.20 - C:\Windows\system32\bash.EXE
Describe the bug
If the current directory doesn't have "correct" uppercase/lowercase letters, playwright won't run any tests and gives a confusing error message because it ignores playwright.config.ts and treats the tests themselves as configuration file(s). For example, it might say "Playwright Test did not expect test.beforeEach() to be called here".
Code Snippet
Powershell transcript using on the example shipped provided with playwright:
PS C:\Dev\Temp\playwright-test> npm init playwright@latest
...
PS C:\Dev\Temp\playwright-test> npx playwright test
Running 3 tests using 3 workers
3 passed (4s)
To open last HTML report run:
npx playwright show-report
PS C:\Dev\Temp\playwright-test> cd /dev/temp/playwright-test
PS C:\dev\temp\playwright-test> npx playwright test
Running 0 test using 0 worker
Error: ui-tests\example.spec.ts:5:16: Playwright Test did not expect test() to be called here.
Most common reasons include:
- You are calling test() in a configuration file.
- You are calling test() in a file that is imported by the configuration file.
- You have two different versions of @playwright/test. This usually happens
when one of the dependencies in your package.json depends on @playwright/test.
...
The bug was originally described in #13092.
Thanks for the report. The error message looks to be particularly confusing in this case. We will review!
Discussed and looks like:
PS C:\Dev\Temp\playwright-test> npm init playwright@latest
PS C:\Dev\Temp\playwright-test> npx playwright test
and
PS C:\Dev\Temp\playwright-test> cd /dev/temp/playwright-test
PS C:\dev\temp\playwright-test> npx playwright test
should behave similarly. Since they are not, this likely means there is a bug in our file resolution logic. However, since there is a workaround for now, marking as a future release milestone. Thanks!
