diff --git a/site/content/guides/api-monitoring.md b/site/content/guides/api-monitoring.md index 394075cb8..a3a79f5d1 100644 --- a/site/content/guides/api-monitoring.md +++ b/site/content/guides/api-monitoring.md @@ -364,7 +364,7 @@ As we increase our monitoring coverage across our APIs, we can also increase the
{{< doc-card class="three-column-card" title="Checkly CLI" description="Understand monitoring as code (MaC) via our Checkly CLI." link="/guides/monitoring-as-code-cli/" >}} -{{< doc-card class="three-column-card" title="End to end monitoring" description="Learn end-to-end monitoring with puppeteer and playwright to test key website flows." link="/guides/end-to-end-monitoring/" >}} +{{< doc-card class="three-column-card" title="End to end monitoring" description="Learn end-to-end monitoring with playwright to test key website flows." link="/guides/end-to-end-monitoring/" >}} {{< doc-card class="three-column-card" title="OpenAPI/Swagger Monitoring" description="OpenAPI and Swagger help users design and document APIs in a way that is readable from both humans and machines." link="/guides/openapi-swagger/" >}}
\ No newline at end of file diff --git a/site/content/guides/end-to-end-monitoring.md b/site/content/guides/end-to-end-monitoring.md index 96a4b22b0..bf6b18901 100644 --- a/site/content/guides/end-to-end-monitoring.md +++ b/site/content/guides/end-to-end-monitoring.md @@ -2,7 +2,7 @@ title: What is End to End Monitoring? Overview with Examples displayTitle: End to end monitoring description: >- - Learn end-to-end monitoring with puppeteer and playwright to test key website flows. Follow our guide that gets you up and running in 10 minutes. + Learn end-to-end monitoring with playwright to test key website flows. Follow our guide that gets you up and running in 10 minutes. author: Giovanni Rago avatar: 'images/avatars/giovanni-rago.png' --- @@ -37,7 +37,7 @@ The industry has learned to struggle with the challenges this approach presents: **All of the above lead to higher costs and slower delivery.** -The appearance of mature **headless browser automation tools, such as {{< newtabref href="https://pptr.dev" title="Puppeteer" >}} and {{< newtabref href="https://playwright.dev" title="Playwright" >}}, offers a response** to many of the above issues by allowing testing in the browser without its GUI, which yields higher speed and stability coupled with lower resource consumption. +The appearance of mature **headless browser automation tools, such as {{< newtabref href="https://playwright.dev" title="Playwright" >}}, offer a response** to many of the above issues by allowing testing in the browser without its GUI, which yields higher speed and stability coupled with lower resource consumption. ## E2E monitoring examples diff --git a/site/content/guides/monitoring-as-code-cli.md b/site/content/guides/monitoring-as-code-cli.md index 0cab415c6..b0a8c72ba 100644 --- a/site/content/guides/monitoring-as-code-cli.md +++ b/site/content/guides/monitoring-as-code-cli.md @@ -385,7 +385,7 @@ Expanding our initial setup from here is easy, please follow these links if you
{{< doc-card class="three-column-card" title="Monitoring as code" description="Why should the way we manage monitoring be any different?" link="/guides/monitoring-as-code/" >}} -{{< doc-card class="three-column-card" title="End to end monitoring" description="Learn end-to-end monitoring with puppeteer and playwright to test key website flows." link="/guides/end-to-end-monitoring/" >}} +{{< doc-card class="three-column-card" title="End to end monitoring" description="Learn end-to-end monitoring with playwright to test key website flows." link="/guides/end-to-end-monitoring/" >}} {{< doc-card class="three-column-card" title="Setup scripts for API monitoring" description="Setup scripts are a fundamental tool to tailor API checks to your own target endpoints." link="/guides/setup-scripts/" >}}
\ No newline at end of file diff --git a/site/content/guides/monitoring-as-code.md b/site/content/guides/monitoring-as-code.md index 3ec1d9c08..345543477 100644 --- a/site/content/guides/monitoring-as-code.md +++ b/site/content/guides/monitoring-as-code.md @@ -509,7 +509,7 @@ As our setup expands, we might want to deploy additional tools to make our lives
{{< doc-card class="three-column-card" title="Checkly CLI" description="Understand monitoring as code (MaC) via our Checkly CLI." link="/guides/monitoring-as-code-cli/" >}} -{{< doc-card class="three-column-card" title="End to end monitoring" description="Learn end-to-end monitoring with puppeteer and playwright to test key website flows." link="/guides/end-to-end-monitoring/" >}} +{{< doc-card class="three-column-card" title="End to end monitoring" description="Learn end-to-end monitoring with playwright to test key website flows." link="/guides/end-to-end-monitoring/" >}} {{< doc-card class="three-column-card" title="Setup scripts for API monitoring" description="Setup scripts are a fundamental tool to tailor API checks to your own target endpoints." link="/guides/setup-scripts/" >}}
\ No newline at end of file diff --git a/site/content/learn/playwright/basics/multitab-flows.md b/site/content/learn/playwright/basics/multitab-flows.md index e89587a67..4ec53bd1a 100644 --- a/site/content/learn/playwright/basics/multitab-flows.md +++ b/site/content/learn/playwright/basics/multitab-flows.md @@ -14,11 +14,11 @@ menu: parent: "Basics" --- -Both Puppeteer and Playwright enable us to control multiple browser tabs, albeit in different ways. +Playwright enables us to control multiple browser tabs, albeit in different ways. ## Opening tabs directly -If we are looking to open brand new tabs with which to interact, the setup is rather straightforward for both Puppeteer and Playwright. +If we are looking to open brand new tabs with which to interact, the setup is rather straightforward. {{< tabs "1" >}} {{< tab "Playwright" >}} @@ -27,12 +27,7 @@ If we are looking to open brand new tabs with which to interact, the setup is ra ``` {{< run-in-checkly "/samples/playwright/multitab-open.js" "playwright" >}} {{< /tab >}} -{{< tab "Puppeteer" >}} -```js -{{< readfile filename="samples/puppeteer/multitab-open.js" >}} -``` -{{< run-in-checkly "/samples/puppeteer/multitab-open.js" "puppeteer" >}} -{{< /tab >}} + {{< /tabs >}} ## Handling links that open a new tab @@ -41,7 +36,6 @@ Controlling tabs that are opened after a click on an element on the page can be By allowing us to wait for the creation of a child tab with `page.waitForEvent`, Playwright enables us to "catch" it following a click on an element with `target="_blank"`, and then seamlessly interact with any of the currently open tabs. -With Puppeteer we need to follow a different procedure, using `page.waitForTarget` to grab the new tab once it has been opened. {{< tabs "2" >}} {{< tab "Playwright" >}} @@ -50,24 +44,10 @@ With Puppeteer we need to follow a different procedure, using `page.waitForTarge ``` {{< run-in-checkly "/samples/playwright/multitab-flows.js" "playwright" >}} {{< /tab >}} -{{< tab "Puppeteer" >}} -```js -{{< readfile filename="samples/puppeteer/multitab-flows.js" >}} -``` -{{< run-in-checkly "/samples/puppeteer/multitab-flows.js" "puppeteer" >}} -{{< /tab >}} + {{< /tabs >}} -Note that, if running Puppeteer in headful mode, you will have to manually bring focus to the new tab, either by bringing it to the front or closing the old one: -{{< tabs "3" >}} -{{< tab "Puppeteer" >}} -```js {hl_lines=["18-21"]} -{{< readfile filename="samples/puppeteer/multitab-headful.js" >}} -``` -{{< run-in-checkly "/samples/puppeteer/multitab-headful.js" "puppeteer" >}} -{{< /tab >}} -{{< /tabs >}} ## Further reading diff --git a/site/content/learn/playwright/basics/request-interception.md b/site/content/learn/playwright/basics/request-interception.md index f2f7cb744..ee742f638 100644 --- a/site/content/learn/playwright/basics/request-interception.md +++ b/site/content/learn/playwright/basics/request-interception.md @@ -36,7 +36,6 @@ Request interception enables us to observe which requests and responses are bein We might want to intervene and filter the outgoing requests. For example, when [scraping web pages](/learn/headless/basics-scraping/), we might want to block unnecessary elements from loading in order to speed up the procedure and lower bandwidth usage. -In the following snippet we are going to abort all requests for images on our test website. We will identify them based off of their [`resourceType`](https://pptr.dev/#?product=Puppeteer&version=v10.2.0&show=api-httprequestresourcetype), while letting all other requests through without modification. {{< tabs "2" >}} {{< tab "Playwright" >}} @@ -58,7 +57,7 @@ In the following snippet we are going to abort all requests for images on our te Isolating one or more software components from their dependencies makes them easier to test. We can do so by substituting interactions with such dependencies with simulated, simplified ones. This is also known as _stubbing_. -Both Playwright and Puppeteer make it easy for us, as for every request we can intercept we also can stub a response. +Playwright makes it easy for us, as for every request we can intercept we also can stub a response. Every time we load it, our test website is sending a request to its backend to fetch a list of best selling books. For our example, we are going to intercept this response and modify it to return a single book we define on the fly. diff --git a/site/content/learn/playwright/basics/taking-screenshots.md b/site/content/learn/playwright/basics/taking-screenshots.md index 83af96a25..7186e5c60 100644 --- a/site/content/learn/playwright/basics/taking-screenshots.md +++ b/site/content/learn/playwright/basics/taking-screenshots.md @@ -20,7 +20,7 @@ Headless browsers are fully capable of taking screenshots, which is very useful ## Generating and saving screenshots -The `page.screenshot` command is consistent across Playwright and Puppeteer, and allows us to save one or more screenshots of the current page to a specified path. Without any additional options, the size of the screenshot depends on the viewport size: +The `page.screenshot` command allows us to save one or more screenshots of the current page to a specified path. Without any additional options, the size of the screenshot depends on the viewport size: {{< tabs "1" >}} {{< tab "Playwright" >}} @@ -28,13 +28,7 @@ The `page.screenshot` command is consistent across Playwright and Puppeteer, and {{< readfile filename="samples/playwright/basic-screenshot.js" >}} ``` {{< run-in-checkly "/samples/playwright/basic-screenshot.js" "playwright" >}} -{{< /tab >}} -{{< tab "Puppeteer" >}} -```js -{{< readfile filename="samples/puppeteer/basic-screenshot.js" >}} -``` -{{< run-in-checkly "/samples/puppeteer/basic-screenshot.js" "puppeteer" >}} -{{< /tab >}} +{{< /tab >}}\s {{< /tabs >}} ## Full page screenshots @@ -56,12 +50,7 @@ Having our screenshot limited to a smaller portion of the viewport is also possi ``` {{< run-in-checkly "/samples/playwright/basic-screenshot-clipped.js" "playwright" >}} {{< /tab >}} -{{< tab "Puppeteer" >}} -```js -{{< readfile filename="samples/puppeteer/basic-screenshot-clipped.js" >}} -``` -{{< run-in-checkly "/samples/puppeteer/basic-screenshot-clipped.js" "puppeteer" >}} -{{< /tab >}} + {{< /tabs >}} The above examples can be run as follows: diff --git a/site/content/learn/playwright/best-practices/challenging-flows.md b/site/content/learn/playwright/best-practices/challenging-flows.md index e26f074d5..fcca32ef2 100644 --- a/site/content/learn/playwright/best-practices/challenging-flows.md +++ b/site/content/learn/playwright/best-practices/challenging-flows.md @@ -13,7 +13,7 @@ menu: parent: "Best practices" --- -While automation tools are fundamental to modern software development, they also have the innate potential to be used for malicious purposes. This applies to Playwright and Puppeteer, too. +While automation tools are fundamental to modern software development, they also have the innate potential to be used for malicious purposes. @@ -56,14 +56,7 @@ const page = await context.newPage('https://example.com') ``` {{< /tab >}} -{{< tab "Puppeteer" >}} - ```js -const browser = await puppeteer.launch() -const page = await browser.newPage() -await page.setUserAgent('Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/79.0.3945.0 Safari 537.36 Secret/') -``` -{{< /tab >}} {{< /tabs >}} ## Automation-resistant UIs diff --git a/site/content/learn/playwright/best-practices/performance.md b/site/content/learn/playwright/best-practices/performance.md index 7d19c80e5..a56458614 100644 --- a/site/content/learn/playwright/best-practices/performance.md +++ b/site/content/learn/playwright/best-practices/performance.md @@ -17,7 +17,7 @@ menu: The need for fast and responsive applications has never been greater because of the move from [desktop to mobile](https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet/worldwide/). Still, web applications have been increasing in [complexity and size](https://httparchive.org/reports/page-weight). It is clear why the topic of webpage performance is more popular today than it ever was. -This article gives a practical introduction to the whys and hows of web performance without getting lost in the depth of this massive topic. It also explains how to measure performance and gather metrics such as the Web Vitals with headless tools such as Puppeteer and Playwright. +This article gives a practical introduction to the whys and hows of web performance without getting lost in the depth of this massive topic. @@ -58,7 +58,7 @@ Not all of Google's Web Vitals are suitable for synthetic monitoring and perform {{}} ## Web Performance evaluation with headless tools -As much as we should be striving to build performant applications, we should commit to monitoring and testing performance to enable continuous feedback and rapid intervention in case of degradation. Playwright and Puppeteer provide a great toolkit to power synthetic monitoring and performance testing. +As much as we should be striving to build performant applications, we should commit to monitoring and testing performance to enable continuous feedback and rapid intervention in case of degradation. Playwright provides a great toolkit to power synthetic monitoring and performance testing. 1. Access to the Web Performance APIs. 2. Whenever testing against Chromium, access to the Chrome DevTools Protocol for traffic inspection, network emulation and more. @@ -83,12 +83,6 @@ The Navigation Timing and the Resource Timing performance APIs are W3C specifica ``` {{< run-in-checkly "/samples/playwright/basic-performance-navigation.js" "playwright" >}} {{< /tab >}} -{{< tab "Puppeteer" >}} -```js -{{< readfile filename="samples/puppeteer/basic-performance-navigation.js" >}} -``` -{{< run-in-checkly "/samples/puppeteer/basic-performance-navigation.js" "puppeteer" >}} -{{< /tab >}} {{< /tabs >}}
@@ -139,12 +133,7 @@ The Navigation Timing and the Resource Timing performance APIs are W3C specifica ``` {{< run-in-checkly "/samples/playwright/basic-performance-resource.js" "playwright" >}} {{< /tab >}} -{{< tab "Puppeteer" >}} -```js -{{< readfile filename="samples/puppeteer/basic-performance-resource.js" >}} -``` -{{< run-in-checkly "/samples/puppeteer/basic-performance-resource.js" "puppeteer" >}} -{{< /tab >}} + {{< /tabs >}}
@@ -187,12 +176,7 @@ The Navigation Timing and the Resource Timing performance APIs are W3C specifica ``` {{< run-in-checkly "/samples/playwright/basic-performance-paint-timing.js" "playwright" >}} {{< /tab >}} -{{< tab "Puppeteer" >}} -```js -{{< readfile filename="samples/puppeteer/basic-performance-paint-timing.js" >}} -``` -{{< run-in-checkly "/samples/puppeteer/basic-performance-paint-timing.js" "puppeteer" >}} -{{< /tab >}} + {{< /tabs >}}
@@ -220,12 +204,7 @@ To evaluate the LCP initialize a `PerformanceObserver`, observe `largest-content ``` {{< run-in-checkly "/samples/playwright/basic-performance-largest-contentful-paint.js" "playwright" >}} {{< /tab >}} -{{< tab "Puppeteer" >}} -```js -{{< readfile filename="samples/puppeteer/basic-performance-largest-contentful-paint.js" >}} -``` -{{< run-in-checkly "/samples/puppeteer/basic-performance-largest-contentful-paint.js" "puppeteer" >}} -{{< /tab >}} + {{< /tabs >}} #### Layout Instability API (`layout-shift`) @@ -242,12 +221,7 @@ Layout shifts are no single event but event streams. To calculate CLS initialize ``` {{< run-in-checkly "/samples/playwright/basic-performance-layout-shift.js" "playwright" >}} {{< /tab >}} -{{< tab "Puppeteer" >}} -```js -{{< readfile filename="samples/puppeteer/basic-performance-layout-shift.js" >}} -``` -{{< run-in-checkly "/samples/puppeteer/basic-performance-layout-shift.js" "puppeteer" >}} -{{< /tab >}} + {{< /tabs >}} #### Long Task API (`longtask`) @@ -265,17 +239,12 @@ Long Tasks are no single event but event streams. To calculate TBT initialize a ``` {{< run-in-checkly "/samples/playwright/basic-performance-long-task.js" "playwright" >}} {{< /tab >}} -{{< tab "Puppeteer" >}} -```js -{{< readfile filename="samples/puppeteer/basic-performance-long-task.js" >}} -``` -{{< run-in-checkly "/samples/puppeteer/basic-performance-long-task.js" "puppeteer" >}} -{{< /tab >}} + {{< /tabs >}} ### Chrome DevTools for performance -If the browser performance APIs are not enough, the Chrome DevTools Protocol offers many great performance tools for us to leverage with Playwright and Puppeteer. +If the browser performance APIs are not enough, the Chrome DevTools Protocol offers many great performance tools for us to leverage with Playwright. One important example is network throttling, through which we can simulate the experience of users accessing our page with different network conditions. @@ -286,19 +255,14 @@ One important example is network throttling, through which we can simulate the e ``` {{< run-in-checkly "/samples/playwright/basic-performance-emulation.js" "playwright" >}} {{< /tab >}} -{{< tab "Puppeteer" >}} -```js -{{< readfile filename="samples/puppeteer/basic-performance-emulation.js" >}} -``` -{{< run-in-checkly "/samples/puppeteer/basic-performance-emulation.js" "puppeteer" >}} -{{< /tab >}} + {{< /tabs >}} The DevTools Protocol is quite extensive. We recommend exploring the [documentation](https://chromedevtools.github.io/devtools-protocol/) and getting a comprehensive overview of its capabilities. ### Additional performance libraries -Lighthouse can easily be used programmatically with Playwright and Puppeteer to gather values and scores for different metrics, like [Time To Interactive (TTI)](https://web.dev/interactive/): +Lighthouse can easily be used programmatically with Playwright to gather values and scores for different metrics, like [Time To Interactive (TTI)](https://web.dev/interactive/): {{< tabs "8" >}} {{< tab "Playwright" >}} @@ -306,11 +270,6 @@ Lighthouse can easily be used programmatically with Playwright and Puppeteer to {{< readfile filename="samples/playwright/basic-performance-lighthouse.js" >}} ``` {{< /tab >}} -{{< tab "Puppeteer" >}} -```js -{{< readfile filename="samples/puppeteer/basic-performance-lighthouse.js" >}} -``` -{{< /tab >}} {{< /tabs >}} All above examples can be run as follows: @@ -320,7 +279,7 @@ $ node measure-performance.js ## Further reading 1. The comprehensive [MDN Web Performance documentation](https://developer.mozilla.org/en-US/docs/Web/Performance) -2. [web.dev's performance section](https://web.dev/learn/#performance) -3. [Web Performance Recipes With Puppeteer](https://addyosmani.com/blog/puppeteer-recipes/) by Addy Osmani +2. [Automatically finding accessibility issues with Playwright](https://www.checklyhq.com/blog/integrating-accessibility-checks-in-playwright-tes/) +3. [web.dev's performance section](https://web.dev/learn/#performance) 4. [Getting started with Chrome DevTools Protocol](https://github.com/aslushnikov/getting-started-with-cdp) by Andrey Lushnikov 5. [Get Started with Google Lighthouse](https://developers.google.com/web/tools/lighthouse#get-started) diff --git a/site/content/learn/playwright/best-practices/scraping-example-purchases.md b/site/content/learn/playwright/best-practices/scraping-example-purchases.md index 81c5dc404..1b6102f88 100644 --- a/site/content/learn/playwright/best-practices/scraping-example-purchases.md +++ b/site/content/learn/playwright/best-practices/scraping-example-purchases.md @@ -13,7 +13,7 @@ menu: parent: "Best practices" --- -Playwright and Puppeteer can be particularly useful when scraping data accessible only behind a login wall. This article shows a practical example of such a case. +Playwright can be particularly useful when scraping data accessible only behind a login wall. This article shows a practical example of such a case. @@ -29,11 +29,7 @@ A combination of UI automation and scraping will allow us to first log in to the {{< readfile filename="samples/playwright/scraping-example-purchases.js" >}} ``` {{< /tab >}} -{{< tab "Puppeteer" >}} -```js -{{< readfile filename="samples/puppeteer/scraping-example-purchases.js" >}} -``` -{{< /tab >}} + {{< /tabs >}} > ⚠️ This example is only intended for learning purposes. Always make sure the website you are planning to scrape allows such behaviour. @@ -63,8 +59,8 @@ node scraping-example-purchases.js > ⚠️ Websites might [restrict headless browser traffic](/learn/headless/challenging-flows/) in order to protect their users from fraud. 2FA will also interfere with the script if enabled. ## Takeaways -1. We can scrape information available behind a login wall with Playwright and Puppeteer. +1. We can scrape information available behind a login wall with Playwright. 2. Some websites might not allow scraping. Always make sure you check their terms of service beforehand. ## Further reading -1. [Basic scraping](/learn/headless/basics-scraping/) with Playwright and Puppeteer +1. [Basic scraping](/learn/headless/basics-scraping/) with Playwright diff --git a/site/content/learn/playwright/best-practices/scraping.md b/site/content/learn/playwright/best-practices/scraping.md index b0fbb34bd..f4caec092 100644 --- a/site/content/learn/playwright/best-practices/scraping.md +++ b/site/content/learn/playwright/best-practices/scraping.md @@ -34,15 +34,9 @@ Below is an example running against our [test site](https://danube-web.shop/), g ``` {{< run-in-checkly "/samples/playwright/basic-get-href-value.js" "playwright" >}} {{< /tab >}} -{{< tab "Puppeteer" >}} -```js 7 -{{< readfile filename="samples/puppeteer/basic-get-href-value.js" >}} -``` -{{< run-in-checkly "/samples/puppeteer/basic-get-href-value.js" "puppeteer" >}} -{{< /tab >}} {{< /tabs >}} -As an alternative, it is also possible to retrieve an [ElementHandle](hhttps://pptr.dev/#?product=Puppeteer&version=v10.2.0&show=api-class-elementhandle) and then retrieve a property value from it. Following is an example printing the `href` value of the first `a` element of our homepage: +As an alternative, it is also possible to retrieve an [ElementHandle](https://playwright.dev/docs/api/class-elementhandle) and then retrieve a property value from it. Following is an example printing the `href` value of the first `a` element of our homepage: {{< tabs "2" >}} {{< tab "Playwright" >}} @@ -51,12 +45,7 @@ As an alternative, it is also possible to retrieve an [ElementHandle](hhttps://p ``` {{< run-in-checkly "/samples/playwright/basic-get-href-handle.js" "playwright" >}} {{< /tab >}} -{{< tab "Puppeteer" >}} -```js 7,8 -{{< readfile filename="samples/puppeteer/basic-get-href-handle.js" >}} -``` -{{< run-in-checkly "/samples/puppeteer/basic-get-href-handle.js" "puppeteer" >}} -{{< /tab >}} + {{< /tabs >}} > The `innerText` property is often used in tests to assert that some element on the page contains the expected text. @@ -72,12 +61,6 @@ Scraping element lists is just as easy. For example, let's grab the `innerText` ``` {{< run-in-checkly "/samples/playwright/basic-get-text-values.js" "playwright" >}} {{< /tab >}} -{{< tab "Puppeteer" >}} -```js 7-9 -{{< readfile filename="samples/puppeteer/basic-get-text-values.js" >}} -``` -{{< run-in-checkly "/samples/puppeteer/basic-get-text-values.js" "puppeteer" >}} -{{< /tab >}} {{< /tabs >}} ## Scraping images @@ -91,12 +74,6 @@ Scraping images from a page is also possible. For example, we can easily get the ``` {{< run-in-checkly "/samples/playwright/basic-get-image.js" "playwright" >}} {{< /tab >}} -{{< tab "Puppeteer" >}} -```js [9,11,12] -{{< readfile filename="samples/puppeteer/basic-get-image.js" >}} -``` -{{< run-in-checkly "/samples/puppeteer/basic-get-image.js" "puppeteer" >}} -{{< /tab >}} {{< /tabs >}} We are using [axios](https://github.com/axios/axios) to make a `GET` request against the source URL of the image. The response body will contain the image itself, which can be written to a file using [fs](https://nodejs.org/api/fs.html). @@ -116,12 +93,6 @@ The code for that could look like this: ``` {{< run-in-checkly "/samples/playwright/basic-get-data-json.js" "playwright" >}} {{< /tab >}} -{{< tab "Puppeteer" >}} -```js -{{< readfile filename="samples/puppeteer/basic-get-data-json.js" >}} -``` -{{< run-in-checkly "/samples/puppeteer/basic-get-data-json.js" "puppeteer" >}} -{{< /tab >}} {{< /tabs >}} The resulting `books.json` file will look like the following: diff --git a/site/content/learn/playwright/best-practices/script-recorders.md b/site/content/learn/playwright/best-practices/script-recorders.md index c5d71eb9e..dea8e8c65 100644 --- a/site/content/learn/playwright/best-practices/script-recorders.md +++ b/site/content/learn/playwright/best-practices/script-recorders.md @@ -13,13 +13,11 @@ menu: parent: "Best practices" --- -With Playwright and Puppeteer, writing scripts manually is not the only option. Since browser automation became possible, there have always been tools trying to simplify script creation. Such instruments aim to help users with little or no scripting skills use automation tools, while also saving more expert users time when creating brand new scripts. +With Playwright, writing scripts manually is not the only option. Since browser automation became possible, there have always been tools trying to simplify script creation. Such instruments aim to help users with little or no scripting skills use automation tools, while also saving more expert users time when creating brand new scripts. Recorders can be used to quickly generate code for a scenario, saving time users would otherwise have to spend inspecting the various pages to find valid selectors. When creating multiple scripts, this adds up to a noticeable amount of time saved. -## Tools to record headless automation scripts - -In the world of headless automation, Microsoft's Playwright and Google's Puppeteer provide recorders. +## How to record automation scripts with Playwright ### Record Playwright scripts with `codegen` @@ -31,11 +29,6 @@ Playwright provides multiple ways to record browser automation scripts. The reco Pro tip: if you're using [the Playwright VS Code extension](https://marketplace.visualstudio.com/items?itemName=ms-playwright.playwright#record-new-tests), you can also record and run scripts in your editor. {{< /info >}} -### Record Puppeteer scripts in Google Chrome - -While the Puppeteer executable doesn't provide a built-in recorder, use the Google Chrome developer tools to give your Puppeteer scripts a headstart. Navigate to the "Recorder" panel and export a Puppeteer script. - -![Puppeteer recorder example](/samples/images/puppeteer-recorder.jpg) ## Using recorders effectively diff --git a/site/content/learn/playwright/debugging/basics.md b/site/content/learn/playwright/debugging/basics.md index ea77c0c55..463d862eb 100644 --- a/site/content/learn/playwright/debugging/basics.md +++ b/site/content/learn/playwright/debugging/basics.md @@ -44,46 +44,25 @@ Given that Headless browser scripts will run without a GUI, a visual assessment One possibility is to adding screenshots in specific parts of the script, to validate our assumptions on what might be happening at a given moment of the execution. For example, before and after a problematic click or page transition: -{{< tabs "1" >}} -{{< tab "Playwright" >}} -```js -... -await page.screenshot({ path: 'before_click.png' }) -await page.click('#button') -await page.screenshot({ path: 'after_click.png' }) -... -``` -{{< /tab >}} -{{< tab "Puppeteer" >}} + ```js ... await page.screenshot({ path: 'before_click.png' }) -await page.waitForSelector('#button') await page.click('#button') await page.screenshot({ path: 'after_click.png' }) ... ``` -{{< /tab >}} -{{< /tabs >}} + Another way to better observe our script's execution is to run in headful mode: -{{< tabs "2" >}} -{{< tab "Playwright" >}} + ```js ... const browser = await chromium.launch({ headless: false, slowMo: 20 }) ... ``` -{{< /tab >}} -{{< tab "Puppeteer" >}} -```js -... -const browser = await puppeteer.launch({ headless: false, slowMo: 20 }) -... -``` -{{< /tab >}} -{{< /tabs >}} + We can then tweak the `slowMo` option, which adds a delay in milliseconds between interactions, to make sure the execution is not too fast for us to follow. @@ -91,18 +70,10 @@ We can then tweak the `slowMo` option, which adds a delay in milliseconds betwee Sometimes we need to try and see the execution through our automation tool's eyes. Added logging can help by taking us step-by-step through every command as it is executed. -{{< tabs "3" >}} -{{< tab "Playwright" >}} ```shell DEBUG=pw:api node script.js ``` -{{< /tab >}} -{{< tab "Puppeteer" >}} -```shell -DEBUG="puppeteer:*" node script.js -``` -{{< /tab >}} -{{< /tabs >}} + ![verbose playwright logs](/samples/images/debugging-logging.png) diff --git a/site/content/learn/playwright/e2e/account-settings.md b/site/content/learn/playwright/e2e/account-settings.md index 98c44e13b..36c574b83 100644 --- a/site/content/learn/playwright/e2e/account-settings.md +++ b/site/content/learn/playwright/e2e/account-settings.md @@ -32,11 +32,7 @@ On our [test site](https://danube-web.shop/), such a test could look as follows: {{< readfile filename="samples/playwright/file-upload.js" >}} ``` {{< /tab >}} -{{< tab "Puppeteer" >}} -```js {hl_lines=["25-28"]} -{{< readfile filename="samples/puppeteer/file-upload.js" >}} -``` -{{< /tab >}} + {{< /tabs >}} {{< tabs "2">}}