docs: js/ts snippets for tests (#6791)

docs/src/test-advanced.md

@@ -13,7 +13,7 @@ Playwright Test supports running multiple test projects at the same time. This i
 
 To make use of this feature, we will declare an "option fixture" for the database version, and use it in the tests.
 
-```ts
+```js
 // my-test.ts
 import { test as base } from 'playwright/test';
 
@@ -31,7 +31,7 @@ const test = base.extend<{ version: string, database: Database }>({
 ```
 
 We can use our fixtures in the test.
-```ts
+```js
 // example.spec.ts
 import test from './my-test';
 
@@ -46,7 +46,7 @@ test('test 2', async ({ version, database }) => {
 ```
 
 Now, we can run test in multiple configurations by using projects.
-```ts
+```js
 // pwtest.config.ts
 import { PlaywrightTestConfig } from 'playwright/test';
 
@@ -89,7 +89,7 @@ Worker-scoped fixtures and `beforeAll` and `afterAll` hooks receive `workerInfo`
 
 Consider an example where we run a new http server per worker process, and use `workerIndex` to produce a unique port number:
 
-```ts
+```js
 // my-test.ts
 import { test as base } from 'playwright/test';
 import * as http from 'http';
@@ -141,7 +141,7 @@ The following information is accessible after the test body has finished, in fix
 - `stderr: (string | Buffer)[]` - array of stderr chunks collected during the test run.
 
 Here is an example test that saves some information:
-```ts
+```js
 // example.spec.ts
 import { test } from 'playwright/test';
 
@@ -154,7 +154,7 @@ test('my test needs a file', async ({ table }, testInfo) => {
 ```
 
 Here is an example fixture that automatically saves debug logs when the test fails:
-```ts
+```js
 // my-test.ts
 import * as debug from 'debug';
 import * as fs from 'fs';
@@ -179,7 +179,7 @@ export default test;
 
 To set something up once before running all tests, use `globalSetup` option in the [configuration file](#writing-a-configuration-file). Similarly, use `globalTeardown` to run something once after all the tests.
 
-```ts
+```js
 // global-setup.ts
 import * as http from 'http';
 
@@ -191,14 +191,14 @@ module.exports = async () => {
 };
 ```
 
-```ts
+```js
 // global-teardown.ts
 module.exports = async () => {
   await new Promise(done => global.__server.close(done));
 };
 ```
 
-```ts
+```js
 // pwtest.config.ts
 import { PlaywrightTestConfig } from 'playwright/test';
 
@@ -214,7 +214,7 @@ export default config;
 It is common for the [fixtures](#fixtures) to be configurable, based on various test needs.
 Playwright Test allows creating "options" fixture for this purpose.
 
-```ts
+```js
 // my-test.ts
 import { test as base } from 'playwright/test';
 
@@ -242,7 +242,7 @@ export default test;
 
 We can now pass the option value with `test.use()`.
 
-```ts
+```js
 // example.spec.ts
 import test from './my-test';
 
@@ -256,7 +256,7 @@ test('my test title', async ({ dirs }) => {
 ```
 
 In addition to `test.use()`, we can also specify options in the configuration file.
-```ts
+```js
 // pwtest.config.ts
 import { PlaywrightTestConfig } from 'playwright/test';
 
@@ -271,7 +271,7 @@ export default config;
 
 Playwright Test uses [expect](https://jestjs.io/docs/expect) under the hood which has the functionality to extend it with [custom matchers](https://jestjs.io/docs/expect#expectextendmatchers). See the following example where a custom `toBeWithinRange` function gets added.
 
-```ts
+```js
 // pwtest.config.ts
 import * as pwtest from 'playwright/test';
 
@@ -296,7 +296,7 @@ const config = {};
 export default config;
 ```
 
-```ts
+```js
 // example.spec.ts
 import { test } from 'playwright/test';
 
@@ -306,7 +306,7 @@ test('numeric ranges', () => {
 });
 ```
 
-```ts
+```js
 // global.d.ts
 declare namespace folio {
   interface Matchers<R> {
@@ -317,7 +317,7 @@ declare namespace folio {
 
 To import expect matching libraries like [jest-extended](https://github.com/jest-community/jest-extended#installation) you can import it from your `globals.d.ts`:
 
-```ts
+```js
 // global.d.ts
 import 'jest-extended';
 ```

docs/src/test-annotations.md

@@ -5,7 +5,7 @@ title: "Annotations"
 
 Sadly, tests do not always pass. Playwright Test supports test annotations to deal with failures, flakiness and tests that are not yet ready.
 
-```ts
+```js
 // example.spec.ts
 import { test } from 'playwright/test';
 

docs/src/test-configuration.md

@@ -17,7 +17,7 @@ See the full list of launch options in [`browserType.launch()`](https://playwrig
 
 See the full list of context options in [`browser.newContext()`](https://playwright.dev/docs/api/class-browser#browsernewcontextoptions) documentation.
 
-```ts
+```js
 // pwtest.config.ts
 import { PlaywrightTestConfig } from 'playwright/test';
 

docs/src/test-fixtures.md

@@ -1,6 +1,6 @@
 ---
 id: test-fixtures
-title: "Test fixtures"
+title: "Fixtures"
 ---
 
 <!-- TOC -->
@@ -18,7 +18,7 @@ Here is how typical test environment setup differs between traditional test styl
 
 ### Without fixtures
 
-```ts
+```js
 // example.spec.ts
 
 describe('database', () => {
@@ -53,7 +53,7 @@ describe('database', () => {
 
 ### With fixtures
 
-```ts
+```js
 // example.spec.ts
 import { test as base } from 'playwright/test';
 
@@ -92,7 +92,7 @@ There are two types of fixtures: `test` and `worker`. Test fixtures are set up f
 
 Test fixtures are set up for each test. Consider the following test file:
 
-```ts
+```js
 // hello.spec.ts
 import test from './hello';
 
@@ -109,7 +109,7 @@ It uses fixtures `hello` and `helloWorld` that are set up by the framework for e
 
 Here is how test fixtures are declared and defined. Fixtures can use other fixtures - note how `helloWorld` uses `hello`.
 
-```ts
+```js
 // hello.ts
 import { test as base } from 'playwright/test';
 
@@ -147,7 +147,7 @@ With fixtures, test organization becomes flexible - you can put tests that make
 Playwright Test uses worker processes to run test files. You can specify the maximum number of workers using `--workers` command line option. Similarly to how test fixtures are set up for individual test runs, worker fixtures are set up for each worker process. That's where you can set up services, run servers, etc. Playwright Test will reuse the worker process for as many test files as it can, provided their worker fixtures match and hence environments are identical.
 
 Here is how the test looks:
-```ts
+```js
 // express.spec.ts
 import test from './express-test';
 import fetch from 'node-fetch';
@@ -164,7 +164,7 @@ test('fetch 2', async ({ port }) => {
 ```
 
 And here is how fixtures are declared and defined:
-```ts
+```js
 // express-test.ts
 import { test as base } from 'playwright/test';
 import express from 'express';

docs/src/test-intro.md

@@ -1,6 +1,6 @@
 ---
 id: test-intro
-title: "Playwright Tests"
+title: "Introduction"
 ---
 
 Playwright Test Runner was created specifically to accommodate the needs of the end-to-end testing. It does everything you would expect from the regular test runner, and more. Playwright test allows to:
@@ -27,9 +27,19 @@ npm i -D playwright
 
 ## First test
 
-Create `tests/foo.spec.ts` to define your test.
+Create `tests/foo.spec.js` (or `tests/foo.spec.ts` for TypeScript) to define your test.
 
 ```js
+const { test, expect } = require('playwright/test');
+
+test('is a basic test with the page', async ({ page }) => {
+  await page.goto('https://playwright.dev/');
+  const name = await page.innerText('.navbar__title');
+  expect(name).toBe('Playwright');
+});
+```
+
+```ts
 import { test, expect } from 'playwright/test';
 
 test('is a basic test with the page', async ({ page }) => {
@@ -43,28 +53,28 @@ Now run your tests:
 
 ```sh
 # Assuming that test files are in the tests directory.
-npx pwtest -c tests
+npx playwright test -c tests
 ```
 
 Playwright Test just ran a test using Chromium browser, in a headless manner. Let's tell it to use headed browser:
 
 ```sh
 # Assuming that test files are in the tests directory.
-npx pwtest -c tests --headed
+npx playwright test -c tests --headed
 ```
 
 What about other browsers? Let's run the same test using Firefox:
 
 ```sh
 # Assuming that test files are in the tests directory.
-npx pwtest -c tests --browser=firefox
+npx playwright test -c tests --browser=firefox
 ```
 
 And finally, on all three browsers:
 
 ```sh
 # Assuming that test files are in the tests directory.
-npx pwtest -c tests --browser=all
+npx playwright test -c tests --browser=all
 ```
 
 Refer to [configuration](./test-configuration.md) section for configuring test runs in different modes with different browsers.
@@ -78,6 +88,11 @@ test('basic test', async ({ page }) => {
   ...
 ```
 
+```ts
+test('basic test', async ({ page }) => {
+  ...
+```
+
 We call these arguments `fixtures`. Fixtures are objects that are created for each test run. Playwright Test comes loaded with those fixtures, and you can add your own fixtures as well. When running tests, Playwright Test looks at each test declaration, analyses the set of fixtures the test needs and prepares those fixtures specifically for the test.
 
 Here is a list of the pre-defined fixtures that you are likely to use most of the time:
@@ -103,6 +118,12 @@ test.only('focus this test', async ({ page }) => {
 });
 ```
 
+```ts
+test.only('focus this test', async ({ page }) => {
+  // Run only focused tests in the entire project.
+});
+```
+
 ### Skip a test
 
 You can skip certain test based on the condition.
@@ -113,18 +134,38 @@ test('skip this test', async ({ page, browserName }) => {
 });
 ```
 
+```ts
+test('skip this test', async ({ page, browserName }) => {
+  test.skip(browserName === 'firefox', 'Still working on it');
+});
+```
+
 ### Group tests
 
 You can group tests to give them a logical name or to scope before/after hooks to the group.
 ```js
-import { test, expect } from 'playwright/test';
+const { test, expect } = require('playwright/test');
 
 test.describe('two tests', () => {
-  test.only('one', async ({ page }) => {
+  test('one', async ({ page }) => {
     // ...
   });
 
-  test.skip('two', async ({ page }) => {
+  test('two', async ({ page }) => {
+    // ...
+  });
+});
+```
+
+```ts
+import { test, expect } from 'playwright/test';
+
+test.describe('two tests', () => {
+  test('one', async ({ page }) => {
+    // ...
+  });
+
+  test('two', async ({ page }) => {
     // ...
   });
 });
@@ -136,17 +177,33 @@ You can use `test.beforeAll` and `test.afterAll` hooks to set up and tear down r
 And you can use `test.beforeEach` and `test.afterEach` hooks to set up and tear down resources for each test individually.
 
 ```js
+const { test, expect } = require('playwright/test');
+
+test.describe('feature foo', () => {
+  test.beforeEach(async ({ page }) => {
+    // Go to the starting url before each test.
+    await page.goto('https://my.start.url/');
+  });
+
+  test('my test', async ({ page }) => {
+    // Assertions use the expect API.
+    expect(page.url()).toBe('https://my.start.url/');
+  });
+});
+```
+
+```ts
 import { test, expect } from 'playwright/test';
 
 test.describe('feature foo', () => {
   test.beforeEach(async ({ page }) => {
     // Go to the starting url before each test.
-    await page.goto('https://my.start.url');
+    await page.goto('https://my.start.url/');
   });
 
   test('my test', async ({ page }) => {
     // Assertions use the expect API.
-    expect(page.url()).toBe('https://my.start.url');
+    expect(page.url()).toBe('https://my.start.url/');
   });
 });
 ```
@@ -155,9 +212,45 @@ test.describe('feature foo', () => {
 
 So far, we've looked at the zero-config operation of Playwright Test. For a real world application, it is likely that you would want to use a config.
 
-Create `pwtest.config.ts` to configure your tests. You can specify browser launch options, run tests in multiple browsers and much more with the config. Here is an example configuration that runs every test in Chromium, Firefox and WebKit.
+Create `playwright.config.js` (or `playwright.config.ts`) to configure your tests. You can specify browser launch options, run tests in multiple browsers and much more with the config. Here is an example configuration that runs every test in Chromium, Firefox and WebKit.
 
 ```js
+module.exports = {
+  timeout: 30000,  // Each test is given 30 seconds.
+
+  // A project per browser, each running all the tests.
+  projects: [
+    {
+      name: 'chromium',
+      use: {
+        browserName: 'chromium',
+        headless: true,
+        viewport: { width: 1280, height: 720 },
+      },
+    },
+
+    {
+      name: 'webkit',
+      use: {
+        browserName: 'webkit',
+        headless: true,
+        viewport: { width: 1280, height: 720 },
+      },
+    },
+
+    {
+      name: 'firefox',
+      use: {
+        browserName: 'firefox',
+        headless: true,
+        viewport: { width: 1280, height: 720 },
+      },
+    }
+  ],
+};
+```
+
+```ts
 import { PlaywrightTestConfig } from 'playwright/test';
 
 const config: PlaywrightTestConfig = {
@@ -196,12 +289,22 @@ const config: PlaywrightTestConfig = {
 export default config;
 ```
 
-Configure NPM script to use config.
+Configure NPM script to run tests. Test runner will automatically pick up `playwright.config.js` or `playwright.config.ts`.
 
 ```json
 {
   "scripts": {
-    "test": "npx pwtest -c config.ts"
+    "test": "npx playwright test"
+  }
+}
+```
+
+If you put your configuration file in a different place, pass it with `--config` option.
+
+```json
+{
+  "scripts": {
+    "test": "npx playwright test --config=tests/example.config.js"
   }
 }
 ```

docs/src/test-reporters.md

@@ -18,7 +18,7 @@ npx playwright test --reporter=line
 
 For more control, you can specify reporters programmatically in the [configuration file](#writing-a-configuration-file).
 
-```ts
+```js
 // pwtest.config.ts
 import { PlaywrightTestConfig } from 'playwright/test';
 
@@ -47,7 +47,7 @@ All built-in reporters show detailed information about failures, and mostly diff
 
 List reporter is default. It prints a line for each test being run. Use it with `--reporter=list` or `reporter: 'list'`.
 
-```ts
+```js
 // pwtest.config.ts
 const config = {
   reporter: 'list',
@@ -76,7 +76,7 @@ Running 124 tests using 6 workers
 
 Line reporter is more concise than the list reporter. It uses a single line to report last finished test, and prints failures when they occur. Line reporter is useful for large test suites where it shows the progress but does not spam the output by listing all the tests. Use it with `--reporter=line` or `reporter: 'line'`.
 
-```ts
+```js
 // pwtest.config.ts
 const config = {
   reporter: 'line',
@@ -102,7 +102,7 @@ Running 124 tests using 6 workers
 
 Dot reporter is very concise - it only produces a single character per successful test run. It is useful on CI where you don't want a lot of output. Use it with `--reporter=dot` or `reporter: 'dot'`.
 
-```ts
+```js
 // pwtest.config.ts
 const config = {
   reporter: 'dot',
@@ -127,7 +127,7 @@ FOLIO_JSON_OUTPUT_NAME=results.json npx playwright test --reporter=json,dot
 ```
 
 In configuration file, pass options directly:
-```ts
+```js
 // pwtest.config.ts
 const config = {
   reporter: { name: 'json', outputFile: 'results.json' },
@@ -145,7 +145,7 @@ FOLIO_JUNIT_OUTPUT_NAME=results.xml npx playwright test --reporter=junit,line
 ```
 
 In configuration file, pass options directly:
-```ts
+```js
 // pwtest.config.ts
 const config = {
   reporter: { name: 'junit', outputFile: 'results.xml' },

docs/src/test-snapshots.md

@@ -5,7 +5,7 @@ title: "Snapshots"
 
 Playwright Test includes the ability to produce and compare snapshots. For that, use `expect(value).toMatchSnapshot()`. Test runner auto-detects the content type, and includes built-in matchers for text, png and jpeg images, and arbitrary binary data.
 
-```ts
+```js
 // example.spec.ts
 import { test } from 'playwright/test';