From 27647587d0266abd006cbeac0c6e0337b887ff8e Mon Sep 17 00:00:00 2001 From: Max Schmitt Date: Mon, 27 Sep 2021 13:53:43 +0200 Subject: [PATCH 1/3] docs: add Playwright to testing envionments --- content/docs/testing-environments.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index 3f1eee5704c..ef45bb85f7f 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -55,4 +55,4 @@ Sometimes, you may not want to mock timers. For example, maybe you're testing an End-to-end tests are useful for testing longer workflows, especially when they're critical to your business (such as payments or signups). For these tests, you'd probably want to test how a real browser renders the whole app, fetches data from the real API endpoints, uses sessions and cookies, navigates between different links. You might also likely want to make assertions not just on the DOM state, but on the backing data as well (e.g. to verify whether the updates have been persisted to the database). -In this scenario, you would use a framework like [Cypress](https://www.cypress.io/) or a library like [puppeteer](https://github.com/GoogleChrome/puppeteer) so you can navigate between multiple routes and assert on side effects not just in the browser, but potentially on the backend as well. +In this scenario, you would use a framework like [Cypress](https://www.cypress.io/), [Playwright](https://playwright.dev/docs/intro) or a library like [Puppeteer](https://github.com/puppeteer/puppeteer) so you can navigate between multiple routes and assert on side effects not just in the browser, but potentially on the backend as well. From 1a5bed333b68a7a6647590fb31b19f029c22853d Mon Sep 17 00:00:00 2001 From: Max Schmitt Date: Mon, 27 Sep 2021 14:30:45 +0200 Subject: [PATCH 2/3] use / instead --- content/docs/testing-environments.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index ef45bb85f7f..8184eae974e 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -55,4 +55,4 @@ Sometimes, you may not want to mock timers. For example, maybe you're testing an End-to-end tests are useful for testing longer workflows, especially when they're critical to your business (such as payments or signups). For these tests, you'd probably want to test how a real browser renders the whole app, fetches data from the real API endpoints, uses sessions and cookies, navigates between different links. You might also likely want to make assertions not just on the DOM state, but on the backing data as well (e.g. to verify whether the updates have been persisted to the database). -In this scenario, you would use a framework like [Cypress](https://www.cypress.io/), [Playwright](https://playwright.dev/docs/intro) or a library like [Puppeteer](https://github.com/puppeteer/puppeteer) so you can navigate between multiple routes and assert on side effects not just in the browser, but potentially on the backend as well. +In this scenario, you would use a framework like [Cypress](https://www.cypress.io/), [Playwright](https://playwright.dev) or a library like [Puppeteer](https://github.com/puppeteer/puppeteer) so you can navigate between multiple routes and assert on side effects not just in the browser, but potentially on the backend as well. From 2763fc79e5811c1a85f6eb582bfa6ab8ff97f61a Mon Sep 17 00:00:00 2001 From: Sebastian Silbermann Date: Tue, 28 Sep 2021 08:50:27 +0200 Subject: [PATCH 3/3] Update content/docs/testing-environments.md --- content/docs/testing-environments.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/testing-environments.md b/content/docs/testing-environments.md index 8184eae974e..df71ebd1974 100644 --- a/content/docs/testing-environments.md +++ b/content/docs/testing-environments.md @@ -55,4 +55,4 @@ Sometimes, you may not want to mock timers. For example, maybe you're testing an End-to-end tests are useful for testing longer workflows, especially when they're critical to your business (such as payments or signups). For these tests, you'd probably want to test how a real browser renders the whole app, fetches data from the real API endpoints, uses sessions and cookies, navigates between different links. You might also likely want to make assertions not just on the DOM state, but on the backing data as well (e.g. to verify whether the updates have been persisted to the database). -In this scenario, you would use a framework like [Cypress](https://www.cypress.io/), [Playwright](https://playwright.dev) or a library like [Puppeteer](https://github.com/puppeteer/puppeteer) so you can navigate between multiple routes and assert on side effects not just in the browser, but potentially on the backend as well. +In this scenario, you would use a framework like [Cypress](https://www.cypress.io/), [Playwright](https://playwright.dev) or a library like [Puppeteer](https://pptr.dev/) so you can navigate between multiple routes and assert on side effects not just in the browser, but potentially on the backend as well.