You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: dev-packages/browser-integration-tests/README.md
+39-16Lines changed: 39 additions & 16 deletions
Original file line number
Diff line number
Diff line change
@@ -1,19 +1,29 @@
1
1
# Integration Tests for Sentry Browser SDK
2
2
3
-
Integration tests for Sentry's Browser SDK use [Playwright](https://playwright.dev/) internally. These tests are run on latest stable versions of Chromium, Firefox and Webkit.
3
+
Integration tests for Sentry's Browser SDK use [Playwright](https://playwright.dev/) internally. These tests are run on
4
+
latest stable versions of Chromium, Firefox and Webkit.
4
5
5
6
## Structure
6
7
7
-
The tests are grouped by their scope such as `breadcrumbs` or `onunhandledrejection`. In every group of tests, there are multiple folders containing test cases with their optional supporting assets.
8
+
The tests are grouped by their scope such as `breadcrumbs` or `onunhandledrejection`. In every group of tests, there are
9
+
multiple folders containing test cases with their optional supporting assets.
8
10
9
-
Each case group has a default HTML skeleton named `template.hbs`, and also a default initialization script named `init.js `, which contains the `Sentry.init()` call. These defaults are used as fallbacks when a specific `template.hbs` or `init.js` is not defined in a case folder.
11
+
Each case group has a default HTML skeleton named `template.hbs`, and also a default initialization script named
12
+
`init.js `, which contains the `Sentry.init()` call. These defaults are used as fallbacks when a specific `template.hbs`
13
+
or `init.js` is not defined in a case folder.
10
14
11
-
`subject.js` contains the logic that sets up the environment to be tested. It also can be defined locally and as a group fallback. Unlike `template.hbs` and `init.js`, it's not required to be defined for a group, as there may be cases that does not require a subject, instead the logic is injected using `injectScriptAndGetEvents` from `utils/helpers.ts`.
15
+
`subject.js` contains the logic that sets up the environment to be tested. It also can be defined locally and as a group
16
+
fallback. Unlike `template.hbs` and `init.js`, it's not required to be defined for a group, as there may be cases that
17
+
does not require a subject, instead the logic is injected using `injectScriptAndGetEvents` from `utils/helpers.ts`.
12
18
13
-
`test.ts` is required for each test case, which contains the assertions (and if required the script injection logic). For every case, any set of `init.js`, `template.hbs` and `subject.js` can be defined locally, and each one of them will have precedence over the default definitions of the test group.
19
+
`test.ts` is required for each test case, which contains the assertions (and if required the script injection logic).
20
+
For every case, any set of `init.js`, `template.hbs` and `subject.js` can be defined locally, and each one of them will
21
+
have precedence over the default definitions of the test group.
14
22
15
-
To test page multi-page navigations, you can specify additional `page-*.html` (e.g. `page-0.html`, `page-1.html`) files. These will also be compiled and initialized with the same `init.js` and `subject.js` files that are applied to `template.hbs/html`. Note: `page-*.html` file lookup **doesn not** fall back to the
16
-
parent directories, meaning that page files have to be directly in the `test.ts` directory.
23
+
To test page multi-page navigations, you can specify additional `page-*.html` (e.g. `page-0.html`, `page-1.html`) files.
24
+
These will also be compiled and initialized with the same `init.js` and `subject.js` files that are applied to
25
+
`template.hbs/html`. Note: `page-*.html` file lookup **doesn not** fall back to the parent directories, meaning that
26
+
page files have to be directly in the `test.ts` directory.
17
27
18
28
```
19
29
suites/
@@ -33,11 +43,16 @@ suites/
33
43
34
44
### Helpers
35
45
36
-
`utils/helpers.ts` contains helpers that could be used in assertions (`test.ts`). These helpers define a convenient and reliable API to interact with Playwright's native API. It's highly recommended to define all common patterns of Playwright usage in helpers.
46
+
`utils/helpers.ts` contains helpers that could be used in assertions (`test.ts`). These helpers define a convenient and
47
+
reliable API to interact with Playwright's native API. It's highly recommended to define all common patterns of
48
+
Playwright usage in helpers.
37
49
38
50
### Fixtures
39
51
40
-
[Fixtures](https://playwright.dev/docs/api/class-fixtures) allows us to define the globals and test-specific information in assertion groups (`test.ts` files). In it's current state, `fixtures.ts` contains an extension over the pure version of `test()` function of Playwright. All the tests should import `sentryTest` function from `utils/fixtures.ts` instead of `@playwright/test` to be able to access the extra fixtures.
52
+
[Fixtures](https://playwright.dev/docs/api/class-fixtures) allows us to define the globals and test-specific information
53
+
in assertion groups (`test.ts` files). In it's current state, `fixtures.ts` contains an extension over the pure version
54
+
of `test()` function of Playwright. All the tests should import `sentryTest` function from `utils/fixtures.ts` instead
55
+
of `@playwright/test` to be able to access the extra fixtures.
41
56
42
57
## Running Tests Locally
43
58
@@ -47,8 +62,7 @@ Tests can be run locally using the latest version of Chromium with:
47
62
48
63
To run tests with a different browser such as `firefox` or `webkit`:
49
64
50
-
`yarn test --project='firefox'`
51
-
`yarn test --project='webkit'`
65
+
`yarn test --project='firefox'``yarn test --project='webkit'`
52
66
53
67
Or to run on all three browsers:
54
68
@@ -60,18 +74,27 @@ To filter tests by their title:
60
74
61
75
You can refer to [Playwright documentation](https://playwright.dev/docs/test-cli) for other CLI options.
62
76
63
-
You can set env variable `PW_BUNDLE` to set specific build or bundle to test against.
64
-
Available options: `esm`, `cjs`, `bundle`, `bundle_min`
77
+
You can set env variable `PW_BUNDLE` to set specific build or bundle to test against. Available options: `esm`, `cjs`,
78
+
`bundle`, `bundle_min`
65
79
66
80
### Troubleshooting
67
81
68
-
Apart from [Playwright-specific issues](https://playwright.dev/docs/troubleshooting), below are common issues that might occur while writing tests for Sentry Browser SDK.
82
+
Apart from [Playwright-specific issues](https://playwright.dev/docs/troubleshooting), below are common issues that might
83
+
occur while writing tests for Sentry Browser SDK.
69
84
70
85
-#### Flaky Tests
71
-
If a test fails randomly, giving a `Page Closed`, `Target Closed` or a similar error, most of the times, the reason is a race condition between the page action defined in the `subject` and the listeners of the Sentry event / request. It's recommended to firstly check `utils/helpers.ts` whether if that async logic can be replaced by one of the helpers. If not, whether the awaited (or non-awaited on purpose in some cases) Playwright methods can be orchestrated by [`Promise.all`](http://mdn.io/promise.all). Manually-defined waiting logic such as timeouts are not recommended, and should not be required in most of the cases.
86
+
87
+
If a test fails randomly, giving a `Page Closed`, `Target Closed` or a similar error, most of the times, the reason is
88
+
a race condition between the page action defined in the `subject` and the listeners of the Sentry event / request.
89
+
It's recommended to firstly check `utils/helpers.ts` whether if that async logic can be replaced by one of the
90
+
helpers. If not, whether the awaited (or non-awaited on purpose in some cases) Playwright methods can be orchestrated
91
+
by [`Promise.all`](http://mdn.io/promise.all). Manually-defined waiting logic such as timeouts are not recommended,
92
+
and should not be required in most of the cases.
72
93
73
94
-#### Build Errors
74
-
Before running, a page for each test case is built under the case folder inside `dist`. If a page build is failed, it's recommended to check:
95
+
96
+
Before running, a page for each test case is built under the case folder inside `dist`. If a page build is failed,
97
+
it's recommended to check:
75
98
76
99
- If both default `template.hbs` and `init.js` are defined for the test group.
Copy file name to clipboardExpand all lines: dev-packages/e2e-tests/test-applications/create-remix-app-express-vite-dev/README.md
+4-2Lines changed: 4 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,7 @@
1
1
# Welcome to Remix + Vite!
2
2
3
-
📖 See the [Remix docs](https://remix.run/docs) and the [Remix Vite docs](https://remix.run/docs/en/main/future/vite) for details on supported features.
3
+
📖 See the [Remix docs](https://remix.run/docs) and the [Remix Vite docs](https://remix.run/docs/en/main/future/vite)
4
+
for details on supported features.
4
5
5
6
## Development
6
7
@@ -28,7 +29,8 @@ Now you'll need to pick a host to deploy it to.
28
29
29
30
### DIY
30
31
31
-
If you're familiar with deploying Express applications you should be right at home. Just make sure to deploy the output of `npm run build`
32
+
If you're familiar with deploying Express applications you should be right at home. Just make sure to deploy the output
Copy file name to clipboardExpand all lines: dev-packages/node-integration-tests/README.md
+20-8Lines changed: 20 additions & 8 deletions
Original file line number
Diff line number
Diff line change
@@ -19,25 +19,37 @@ utils/
19
19
|---- server.ts [default Express server configuration]
20
20
```
21
21
22
-
The tests are grouped by their scopes, such as `public-api` or `tracing`. In every group of tests, there are multiple folders containing test scenarios and assertions.
22
+
The tests are grouped by their scopes, such as `public-api` or `tracing`. In every group of tests, there are multiple
23
+
folders containing test scenarios and assertions.
23
24
24
-
Tests run on Express servers (a server instance per test). By default, a simple server template inside `utils/defaults/server.ts` is used. Every server instance runs on a different port.
25
+
Tests run on Express servers (a server instance per test). By default, a simple server template inside
26
+
`utils/defaults/server.ts` is used. Every server instance runs on a different port.
25
27
26
-
A custom server configuration can be used, supplying a script that exports a valid express server instance as default. `runServer` utility function accepts an optional `serverPath` argument for this purpose.
28
+
A custom server configuration can be used, supplying a script that exports a valid express server instance as default.
29
+
`runServer` utility function accepts an optional `serverPath` argument for this purpose.
27
30
28
-
`scenario.ts` contains the initialization logic and the test subject. By default, `{TEST_DIR}/scenario.ts` is used, but `runServer` also accepts an optional `scenarioPath` argument for non-standard usage.
31
+
`scenario.ts` contains the initialization logic and the test subject. By default, `{TEST_DIR}/scenario.ts` is used, but
32
+
`runServer` also accepts an optional `scenarioPath` argument for non-standard usage.
29
33
30
-
`test.ts` is required for each test case, and contains the server runner logic, request interceptors for Sentry requests, and assertions. Test server, interceptors and assertions are all run on the same Jest thread.
34
+
`test.ts` is required for each test case, and contains the server runner logic, request interceptors for Sentry
35
+
requests, and assertions. Test server, interceptors and assertions are all run on the same Jest thread.
31
36
32
37
### Utilities
33
38
34
39
`utils/` contains helpers and Sentry-specific assertions that can be used in (`test.ts`).
35
40
36
-
`TestEnv` class contains methods to create and execute requests on a test server instance. `TestEnv.init()` which starts a test server and returns a `TestEnv` instance must be called by each test. The test server is automatically shut down after each test, if a data collection helper method such as `getEnvelopeRequest` and `getAPIResponse` is used. Tests that do not use those helper methods will need to end the server manually.
41
+
`TestEnv` class contains methods to create and execute requests on a test server instance. `TestEnv.init()` which starts
42
+
a test server and returns a `TestEnv` instance must be called by each test. The test server is automatically shut down
43
+
after each test, if a data collection helper method such as `getEnvelopeRequest` and `getAPIResponse` is used. Tests
44
+
that do not use those helper methods will need to end the server manually.
37
45
38
-
`TestEnv` instance has two public properties: `url` and `server`. The `url` property is the base URL for the server. The `http.Server` instance is used to finish the server eventually.
46
+
`TestEnv` instance has two public properties: `url` and `server`. The `url` property is the base URL for the server. The
47
+
`http.Server` instance is used to finish the server eventually.
39
48
40
-
Nock interceptors are internally used to capture envelope requests by `getEnvelopeRequest` and `getMultipleEnvelopeRequest` helpers. After capturing required requests, the interceptors are removed. Nock can manually be used inside the test cases to intercept requests but should be removed before the test ends, as not to cause flakiness.
49
+
Nock interceptors are internally used to capture envelope requests by `getEnvelopeRequest` and
50
+
`getMultipleEnvelopeRequest` helpers. After capturing required requests, the interceptors are removed. Nock can manually
51
+
be used inside the test cases to intercept requests but should be removed before the test ends, as not to cause
* Originally coming from [devtools-samples](https://github.com/GoogleChrome/devtools-samples/tree/4818abc9dbcdb954d0eb9b70879f4ea18756451f/jank), licensed under Apache 2.0.
This is a small utility packages for all the Rollup configurations we have in this project. It contains helpers to create standardized configs, custom rollup plugins, and other things that might have to do with the build process like polyfill snippets.
3
+
This is a small utility packages for all the Rollup configurations we have in this project. It contains helpers to
4
+
create standardized configs, custom rollup plugins, and other things that might have to do with the build process like
5
+
polyfill snippets.
4
6
5
7
This package will not be published and is only intended to be used inside this repository.
0 commit comments