Testing for the Modern Web with Playwright

Rate this content

The modern web platform is continuously evolving. Today's web apps are more sophisticated than ever before and testing for the modern web requires modern primitives. In this talk, we will cover how Playwright is uniquely enabling web developers to ship faster and more confidently.

30 min
15 Jun, 2021


Sign in or register to post your comment.

AI Generated Video Summary

Arjun introduces Playwright, a library for cross-browser end-to-end testing of web applications. The challenges in modern web testing include the evolving web platform and reactive frameworks. Playwright provides capable, reliable, and fast automation, with the ability to capture events and enhance test reliability. It uses browser contexts for faster execution and supports multiple languages and frameworks. Playwright is used by companies like VS Code, Bing, Adobe, and material UI, and offers cross-browser support and an improving roadmap.

1. Introduction to Testing the Modern Web

Short description:

Hi, my name is Arjun, and I'm excited to be here at Test.js and talk to you about testing. I'm a program manager at Microsoft where my team is building Playwright. Playwright is a new library for cross-browser end-to-end testing of web applications. In this talk I'm going to talk to you about testing the modern web. My team and I have interacted with hundreds of testers and developers that are building modern web applications, and we've shaped Playwright for their needs.

Hi, my name is Arjun, and I'm excited to be here at Test.js and talk to you about testing. I'm a program manager at Microsoft where my team is building Playwright. Playwright is a new library for cross-browser end-to-end testing of web applications.

In this talk I'm going to talk to you about testing the modern web. My team and I have interacted with hundreds of testers and developers that are building modern web applications, and we've shaped Playwright for their needs. I'm also going to show you the core ideas behind Playwright and hopefully convince you why Playwright is the right testing tool if you're building a modern web application.

Let's jump right in. Let's start by talking about the modern web platform. The modern web platform is more capable than ever before. Web browsers have matured significantly over the last few years. They run on every device we have, including our desktop, our phones, and smart TVs. There's also been a continuous inflow of new features on the web platform. For example, the web can now detect your current location, it can connect to Bluetooth devices, and also interact with your file system. The pace of innovation in the web platform has been incredible.

2. Challenges in Modern Web Testing

Short description:

These changes in the web platform have powered innovation in the application world. Web applications of today are full-blown applications with rich and responsive interactions. Teams are struggling to automate all parts of their application due to the evolving web platform and the challenges posed by reactive frameworks. This has resulted in end-to-end tests slowing teams down instead of helping them move faster. Modern web testing needs to be capable, reliable, and fast to keep up with the changing web landscape.

These changes in the web platform have powered innovation in the application world. If you look at desktop applications, they're very similar to what they were 10 years ago, but web applications look very different. Web applications of today are full-blown applications that have rich and responsive interactions. We're building single-page applications that are built with newer reactive JavaScript frameworks. We're also building PWAs that are replacing native applications. The platform and our applications on the web have both evolved significantly.

With these changes, we've also seen changes in how teams are operating. Teams of developers and testers are actually moving faster. Lots of teams are building applications today, and there's competitive pressures which are pushing teams to ship faster, because that is how they achieve their business goals. This has led to teams adopting newer workflows like CI, CD, and continuous deployment. And teams are also looking for automated testing solutions so that they can release even faster. Unfortunately, end-to-end testing has not evolved as quickly as the web itself. Let's talk a little bit more about that.

End-to-end testing needs to actually evolve for the changes that we talked about in the modern web. For example, tests need to be able to automate newer platform features that are showing up across browsers. These include capabilities that are available on desktop browsers, capabilities that are available on mobile browsers, and even capabilities that are being powered in smart TVs. Teams are actually struggling to be able to automate all parts of their application because their tests cannot actually cover all the capabilities that they're using. The applications of today are also harder to automate. Tests cannot keep up with how reactive frameworks work. And so teams that are building rich single-page applications find that their end-to-end tests are flaky. They're not able to reliably automate user interactions on their applications. What happens as a result is that end-to-end tests that are actually supposed to help you move faster are actually slowing teams down. Teams end up having to add sleep timeouts or retries to be able to manage reliability issues. Teams are struggling with coverage issues because they're not able to automate all parts of their application. And therefore, end-to-end tests are actually slowing teams down when they actually need to be able to ship faster. These three problems are actually the reason why end-to-end testing has not been able to evolve for the modern web. And these three actually give us really the three pillars of modern web testing. Modern web testing needs to be capable so that it can actually automate all possible capabilities of the modern web platform. Modern web testing also needs to be reliable, which means it needs to be able to reliably automate user interactions with highly rich and responsive web applications. And finally, modern web testing needs to be fast, which means it needs to be able to speed up our shipping and release processes instead of slowing them down.

3. Capabilities of Playright for Modern Web Testing

Short description:

Any testing solution for the modern web needs to cover capable, reliable, and fast. Playright is focused on capable automation without trade-offs, reliable automation without flakiness, and fast execution. You can use Playright to automate browser interactions, launch instances of Chromium, Firefox, and WebKit, and test across all platforms. Playright allows for running browsers in headless and head-full modes, providing flexibility for testing modern web applications.

Any testing solution for the modern web needs to cover capable, reliable, and fast, the three pillars of modern web testing. We've actually focused on these three core ideas while building Playright, which means Playright is actually focused on capable automation without any trade-offs. It's also focused on reliable automation without any flakiness or time odds. And finally, Playright enables fast execution, just like unit tests. And so you can actually use end-to-end tests with Playright to be able to actually speed up your test workflows and not slow them down.

For the rest of the talk, I'm going to zoom into each of these three core ideas and actually show you code on how they are actually implemented in Playright and how you can actually make the most use of them in your tests while you're actually shipping your applications. Let's start with capable. Capable automation without trade-offs. Let's start and look at some code. So what I have here is a very simple snippet that uses Playright in JavaScript. Now, Playright is, at its core, a tool for you to write end-to-end tests for your web application, which means with the Playright API, you can actually automate browser interactions. You can launch a browser and automate interactions that are happening inside that browser window. In this particular code snippet, I'm actually using Playright to launch an instance of Chromium. Now, Chromium is the browser engine that's actually used inside Google Chrome and Microsoft Edge. Once I've launched that browser, I'm then opening a new page, which means I'm opening a new tab in that particular browser window with Playright. And then, that particular page is navigating to the TestJS homepage. Finally, I'm closing the browser and wrapping up my basic script. Playright is enabling this, which means you can actually use Playright to automate Chromium. Along with Chromium, you can also use Playright to automate Firefox and WebKit. These three really make Playright the right cross-browser testing tool for the modern web, as Chromium, Firefox, and WebKit actually cover the three main browser engines that are used in modern browsers today. We've talked about Chromium, which powers Microsoft Edge and Google Chrome, Firefox powers Mozilla Firefox, and WebKit is the browser engine used inside Apple Safari. Playright provides you an API that can basically automate all the three browsers. In this particular code snippet, we're actually launching an instance of WebKit and then doing the same interaction. One notable thing here is that Playright WebKit is actually available across all platforms, which means you can actually use WebKit to test for Safari issues in your Linux CI environments, for example, and that's made possible with Playright.

Let's see how more of these capabilities work. With Playright, you can actually have browsers running in both headless and head-full modes. This means that I can actually run my tests on CI in headless modes, so that the UI is not visible and my tests actually run faster. But I can also run these tests locally in head-full mode, where I'm actually looking at the UI and seeing what has happened in the browser. This functionality, again, is available across all platforms. When we are testing for our modern web applications today, it's not just about testing them on our desktop environments.

4. Capabilities of Playwright and Reliability

Short description:

We can emulate mobile environments, use newer web features, intercept network activity, and automate interactions across multiple pages with Playwright. It provides automation without tradeoffs, coverage for modern web platform APIs, and solves the problem of flaky tests by listening to browser events.

We are also building applications for mobile devices. With Playwright, we can actually emulate mobile environments with our cross-browser tests. So when I'm launching an instance of WebKit now, I'm actually specifying that the WebKit page should emulate the iPhone 11 device. This means that my page will have the right viewport just as an iPhone 11, and would enable mobile-specific features like touchscreen events.

Now, talking more about capabilities, we talked about how the web today can detect your current location. When you're launching a browser with Playwright, you can actually use these newer web features. In this particular snippet, I'm actually launching the browser and specifying dark mode to be enabled. I'm also then specifying a particular geolocation for that browser window. I'm specifying a bunch of permissions and local. This way, my browser is actually working as if I have a mock current location. It gives you a quick preview of how Playwright enables newer web features so that you can actually test your applications for those capabilities.

The other important capability that I want to highlight here is that Playwright can also intercept network activity. In this particular snippet, when I launched a browser and created a new page, I set up a mock API so that my API endpoint essentially returns an error code. This gives me the ability to actually test for an error scenario with Playwright's network capabilities. And then finally, another capability to highlight is that Playwright can actually automate interactions across multiple pages. You're not limited to one particular page. In this example, I'm launching an instance of the browser, creating a new page on it, and then opening a new popup. We can then automate that popup with Playwright.

What we just saw was automation without tradeoffs. You were able to automate all modern web browsers, you were able to get headless and head full execution across all platforms. You also saw device emulation for mobile testing, and the best coverage for modern web platform APIs. If you're using any of these APIs, Playwright is really the best tool to be able to author and create your end-to-end tests so that you can actually ensure that all features of your application are covered with your end-to-end tests. That wraps up the capabilities section.

Let's now talk about reliability. As we just talked about earlier, reliability is essentially the problem of being able to automate user interactions on your application without having your tests flake. In a lot of cases, users have to actually author timeouts, which means they need to make their tests sleep for some time so that they can actually reliably automate. This creates a whole bunch of problems because timeouts actually lead to flakiness. Playwright solves these problems in a very unique way. Let's see how. The key thing to note about Playwright is that Playwright can actually listen to browser events.

5. Capturing Events and Enhancing Test Reliability

Short description:

Playwright can capture events from the browser and understand the application's behavior. By launching a browser instance, creating a new page, and setting up event listeners, you can capture console logs and other events like DOM content loaded. These event listeners enhance the reliability of your tests.

It can actually get events from the browser and actually understand what's happening in your application when it's running inside the browser. In this particular snippet, I'm launching an instance of Firefox, I'm creating a new page, and then I'm setting up a new event listener for that particular page. I'm basically saying whenever my application throws a console log it should show up in my test. Playwright is not limited to console logs. I can also listen for other events, such as the DOM content loaded event. The DOM content loaded event is an important lifecycle event when your application or your web page is actually loaded inside the browser. And I can actually listen for this event as a part of my test.

6. Listening to Events and Enhancing Reliability

Short description:

Playwright's ability to listen to events gives it the power to wait for precise events, making tests highly reliable. Playwright's page.click method automatically waits for the right conditions, such as element visibility, animation completion, and click event reception. This eliminates the need for custom wait conditions or sleep timers, making tests easier to write and maintain. Playwright also provides APIs for custom wait conditions, ensuring precise and reliable testing. This feature sets Playwright apart from other testing tools and enhances reliability.

I can also listen to network activity. For example, I can check for whether a particular web socket connection has been opened. This ability to listen to events gives Playwright the ability to wait for precise events instead of having to wait for blankets and sleep timers. This makes your tests highly reliable.

Playwright uses this functionality internally on every interaction. In this snippet, I'm launching an instance of Firefox and then I'm going to github.com and then I'm clicking on a button. Notice that I did not have to use any sleep timers. This is because the page.click in Playwright is automatically waiting for the right conditions. It's waiting for the element to be visible, it's waiting for the element to stop animating, it's waiting for the element to receive click events. All of this is internally done for you so that your user interactions can reliably go to your applications and test your applications. This makes your tests significantly easier to write and maintain over time, because you don't have to worry about custom wait conditions or sleep timers. In a lot of cases, these defaults just work out of the box, but in case you're looking for more control, Playwright also provides you APIs to actually offer your own custom wait for conditions. Now, these wait for conditions, again use the same entire event logic, which means that you don't have to worry about guessing the amount of time this would take. You can actually write that precise condition and make sure that your tests actually wait for it. Now, this essentially shows how Playwright is more reliable. It essentially means that you don't need to actually guess on how long something would take. You can actually use events to verify that application state. And this is, you know, wrapped up automatically for all interactions inside Playwright, which means everything that you do in Playwright has built-in auto waits and retries. And then finally, you know, if your application requires custom logic, you have powerful wait for APIs that you can use and actually author your wait for conditions. This feature differentiates Playwright from other testing tools and actually improves reliability.

7. Fast Execution and Browser Contexts

Short description:

Developers and testers are generally happy with their unit tests as they run reliably and are fast to execute. However, end-to-end tests can be slow due to the dependence on browsers. Playwright introduces a new abstraction called browser contexts to solve this problem. Browser contexts allow for hosting multiple web pages and can be created cheaply, significantly speeding up tests. These contexts are completely isolated from each other, enabling concurrent, isolated testing. Browser contexts also enable emulation, allowing tests to be run across multiple devices.

Now let's talk about fast execution, you know, developers and testers are generally very happy with their unit tests because unit tests run reliably and are fast to execute. However, that's not the case with end-to-end tests because end-to-end tests depend on browsers and browsers can be slow, especially when it comes to launching and closing a browser. If you're running hundreds of tests, being able to sort of run hundreds of browsers is a very expensive operation and that actually drastically makes your tests slower.

To solve this in Playwright, we've actually introduced a new abstraction there. Let's walk through this code snippet to show you how it works. So in this snippet, I'm using Playwright to launch an instance of WebKit, which is the browser engine used inside Apple Safari. Now in this browser instance, I'm actually creating a new context with the browser.newcontext API. Despite the context, I'm then now opening my pages and doing interactions like I was doing earlier. What we've done here is that we've created a new abstraction layer on top of this browser instance called the browser context. This browser context essentially can host multiple web pages inside it. Now, it's very cheap to create browser contexts, which means you can actually spin up multiple contexts without having to worry about the time it takes to launch and close a browser. This significantly speeds up your tests.

Now, there are a few properties of browser contexts that I want to highlight. The first is that browser contexts are actually completely isolated from each other, which means that you can actually create multiple browser contexts, run isolated tests without having to worry that they would affect each other. In this particular code snippet, I'm actually launching an instance of Firefox, and then I'm creating two contexts in it. The first context is an empty context, and the second context is context with authentication. In the second context, I'm adding particular cookies. Now, this essentially means I can actually run my test in two different scenarios. The first is no authentication, empty state, which is a great way to test your marketing websites. The second context is context with authentication, which means you can actually test for workflows that require authentication. Cookies in the second context will not affect the first context. This basically ensures that if we have hundreds of tests, they can run in concurrent, isolated environments through browser contexts without having to spend time to launch and close browsers.

The other interesting thing that browser contexts enable is emulation. We looked at how you can use Playwright to automate device testing for iPhone or iPad devices. In this particular example, I'm actually launching an instance of WebKit, and then I'm actually specifying the two devices I want to test, the iPhone 11 and the iPad Pro 11. When I'm creating this browser instance, I can then create browser contexts on it. I'm basically looping over the devices to test and essentially creating a new context for every device that I want to test. Once I have that browser context, I can then open multiple pages inside it and navigate to the pages that I want to. This essentially means that we had one browser instance but we were able to actually reuse that browser instance in form of browser contexts to be able to run multiple tests across multiple devices. Browser contexts, therefore, not only make your tests faster, they also give you a lot more capability to be able to run emulation scenarios, for example.

8. Playwright: Faster, Capable, and Reliable

Short description:

Playwright makes end-to-end tests faster by using browser contexts for parallelized execution. It enables capable, reliable, and fast automation, supports multiple languages and frameworks, and can be used in any CI-CD environment. Learn more at playwright.dev, GitHub, and join our Slack community.

This is essentially how Playwright is making your end-to-end tests a lot faster, right? Despite browsers being slow, we're able to create a new abstraction layer called browser contexts which are much faster. Browser context parallelizes execution with a single instance, which means you can just launch one browser but then actually create parallelized execution environments. Each of them are isolated from the other, and you can have multiple pages being opened inside one browser context. This makes your tests significantly faster and gives you more capabilities like we just talked about.

Capable, reliable, and fast. These are essentially the three core ideas behind Playwright. We've talked about how Playwright enables capable automation without trade-offs, how it enables reliable automation without having to worry about flakiness or time outs, and how it enables fast execution, just like your unit tests.

To use Playwright, just use npm, installed Playwright can set you up with the latest stable version. When you install Playwright for the first time, it will download your browsers, which means you're ready to go for cross-browser testing. If you prefer to use something else other than JavaScript, you can also use Playwright in other languages. Playwright fits your preferred toolkit, which means you can use Playwright in JavaScript, Python, C-Sharp, or even Java. You can also use Playwright with any test framework and any assertion library and deploy it to your preferred CI-CD environment.

And finally, you know, to learn more about Playwright, just wrapping it up with a few interesting links. The first is our documentation website at playwright.dev. You can also find us on GitHub in the Microsoft org under the Playwright repo name. And finally, you can join our Slack to actually interact with other users who are using Playwright for their end-to-end tests and also reach out to the Playwright team. We are all on Slack. Thank you so much for attending this talk.

9. Companies Using Playwright and Its Capabilities

Short description:

Playwright is an open source repository that has been used by thousands of developers and testers across different language bindings, including JavaScript, Python, and Java. Internal teams like VS Code and Bing, as well as external teams like Adobe and the material UI library, are among the users of Playwright. It offers capabilities that Cypress cannot fully automate, such as automation scenarios across domains and native input events. Playwright focuses on automation without trade-offs and is suitable for tests that require high capability automation tooling. It also fills gaps in the market that Cypress does not address, such as support for different languages like Python and Java.

Hey, welcome. Are you happy with these numbers, 18% of the people saying that they're going to check it out? Yeah. I'm always excited to see folks trying out new tools. Playwright is something that we released last year and we've been seeing a good yearly summary with our sort of rising star summary and the state of JavaScript survey. And it's exciting to see the interest and excitement around Playwright. And I'm sure it'll only grow and we'll be constantly sort of tracking those numbers and making sure that we are actually satisfying that interest with the product.

Yeah, so you're talking about adaptations. So can you share some insights, maybe some secrets about companies that are using Playwright? Yeah, so we released Playwright as an open source repository almost a year ago. In fact, 21st January last year and we released 1.0 in May. So we've been ready for production really for about seven ish months now. And since then we've actually have thousands of developers and testers use Playwright across the different sort of language bindings. So you can use Playwright in JavaScript or Python and recently also released Java support. There are a bunch of internal teams that are using Playwright. So the VS Code team for example is testing everything on Playwright. The Bing team runs about 40,000 tests on Playwright and there are a bunch of external teams that are also using Playwright. Adobe is a big customer. They have a bunch of teams internally who are using Playwright. In terms of open source projects, the material UI library is a big Playwright user. We actually recently upgraded our home page so if you go to Playwright.dev it actually shows logos of customers and that's a good place to track just the big names that are on the Playwright train. Well, probably after today we're going to be able to add some logos on the website home page.

I want to go and ask you two questions from our audience. The first one is from Aaron McAdam. Which particular use cases is Playwright good for when you're comparing to Cypress? Sure, yeah. You know Cypress is an amazing tool and we're very impressed with their developer experience. In general, we've tried to focus on, to begin with, we've tried to focus on some of the scenarios that Cypress cannot fully automate. For instance, if you want to actually run automation scenarios that are across domains, across multiple pages, across domain iframes, Playwright is super appropriate for that. If you want to have tests that involve native input events, so even like hovers or touch screen events, some of these capabilities are much easier to do in Playwright. In general, Playwright has very few trade-offs and our pitch really is automation without trade-offs, so if your tests actually require high capability automation tooling, Playwright is the right tool for you. In general, aside from sort of the capability question, Playwright is also sort of focused on a few sort of gaps in the market that Cypress is not essentially focused on. For example, if you prefer a different language, if your team actually prefers using something like Python or Java for automated testing, you can actually use that with Playwright itself and get the speed and reliability improvement that Playwright makes available in JavaScript.

10. Cross-Browser Support and Roadmap

Short description:

Other languages are possible. Cross-browser support on Playwright is better, including testing for WebKit. Playwright's roadmap focuses on improving the authoring and debugging experience. The integrated test runner simplifies getting started, and upcoming releases will include a debugging UI. Playwright values user feedback and encourages participation in shaping the roadmap through GitHub and Slack.

So, other languages are also possible. Even cross-browser support on Playwright is better in the sense that you can actually test for WebKit, which is the browser engine used inside Apple Safari. And notably, the Playwright support for WebKit is cross-platform. means you can actually use WebKit testing on Mac OS or on Linux or Windows. So, if you have a mobile web application, which is used by users on Safari, and you have a Linux CI CD agent, you can actually use Playwright to run your automated tests for WebKit essentially. So, better browser support, better language bindings, and capability, automation really without any tradeoffs is really our pitch for Cypress.

Super nice that you can also run this WebKit on a Windows machine. I think that really helps if you have a big team when people are using Mac OS and Linux and Windows, of course. Super powerful, I guess.

Next question is from Danny. Can you share something about your roadmap for this in the upcoming year? Yeah, for sure. I think what's been amazing actually is we've seen lots of amazing traction over the last one year. And with any sort of new tool, there's tons of user feedback, tons of GitHub issues or Slack community messages or just engaged users getting onto conversations with us. And that is essentially what's helping us shape our roadmap for this year. Our current focus is on making the getting started experience of authoring your tests even easier. And sort of debugging your tests easier. So one of the things that we released in preview last year was a test runner, an integrated test runner for Playwright. Which means you don't actually necessarily have to use something like Mocha or Jest and figure that integration for yourself. With the integrated test runner, you'll actually get a full, complete end-to-end testing tool which would simplify the experience of getting started significantly. Similarly, maintaining your tests over time is obviously the hardest part when it comes to end-to-end testing and better debugging is something that a lot of our users have asked for and something that we are... We always wanted to build that, but this is a priority for this quarter. We've been doing monthly releases. Playwright 1.8 was live last week. Playwright 1.9 goes live in February and actually has an amazing debugging UI which will actually help you maintain your tests over time. So, lots of authoring and debugging improvements, really, which will be live over the next quarter or so. And that's really our priority. So, that's our roadmap for Playwright. And people can just influence it by joining your Slack server, I understand. So, Danny, if you want to influence it, you can do it. Yeah, you know, I think that's the beauty of- Oh, sorry. Go ahead. Yeah, I was just saying, you know, that's the beauty of open source software, right? I mean, GitHub issues or Slack, you know, our product development and roadmap is fully transparent and we are always seeking feedback. All right. So, Danny, if you want to add something to the roadmap, you can just do it yourself. For the rest of the questions, Arjun is now going to go to his speaker room. And if you have want to talk to him more about Playwright, now is the time. Arjun, I want to thank you a lot for joining us here. And I hope to see you again soon at the next big event.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
TestJS Summit 2022TestJS Summit 2022
20 min
Testing Web Applications with Playwright
Testing is hard, testing takes time to learn and to write, and time is money. As developers we want to test. We know we should but we don't have time. So how can we get more developers to do testing? We can create better tools.
Let me introduce you to Playwright - Reliable end-to-end cross browser testing for modern web apps, by Microsoft and fully open source. Playwright's codegen generates tests for you in JavaScript, TypeScript, Dot Net, Java or Python. Now you really have no excuses. It's time to play your tests wright.
TestJS Summit 2022TestJS Summit 2022
21 min
Tiny Tests, Large Results
Yes, Big things do come in small packages. For example, isn’t a unit test’s speed, feedback, and reliability fantastic? Did you know we can also have fast, focused, and reliable feedback from our functional e2e tests? Atomic e2e tests are those that are targeted and focused. They’re tiny in size but large in their impact. This tutorial will teach you how to create atomic e2e tests with several code examples. First, we will use Cypress.io to authenticate by setting a cookie. Instead of using a UI. Second, we will use Cypress.io to set a JSON Web Token for authentication. Join me, and let’s write tiny tests for large results.
TestJS Summit 2022TestJS Summit 2022
17 min
Testing Mail Service With Playwright
We send emails to our users - account verification and newsletters. We allow the user to contact us by sending an email via inbuild form. Do we? Does the user receive an account verification email or exactly what notification they signed up for? We can cover this functionality as part of E2E tests: get an email and open it to check what is in it. We will need Playwright and a fake SMTP server to capture emails sent by the app.
TestJS Summit 2022TestJS Summit 2022
21 min
E2E Tests for Web3 Applications
We will go through a brief explanation of what is Web3 and the architecture of a web3 application. Then we will talk about how to end-to-end test, its challenges, some test tools that are available, and a demo using cypress and metamask.
Agenda: What is Web3; The Architecture of a Web3 Application; Web3 E2E Tests Introduction; Web3 E2E Tests Challenges; E2E Test Tools; Demo.
React Advanced Conference 2022React Advanced Conference 2022
29 min
How I Test a Million UI States with Every Merge — Visual Testing with Storybook
Error state, loading state, awkward breakpoint, bad data, poor formatting, browser support. Every component can result represent hundreds or thousands of discrete visual states. How do you test it? Manually disable the network — temporarily. Insert bad code — just for a minute. Paw at the edge of your screen. Hack local database fixtures to bits. Frontend development has so many dimensions. Time and variation result in an infinite number of UI possibilities. In this talk, we'll use Storybook to progressively develop, test, and document our work — automating the grunt work of UI development.

Workshops on related topic

React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and
used by React Native itself
as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
- iOS/Android: MacOS Catalina or newer
- Android only: Linux
Install before the workshop
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.

TestJS Summit 2021TestJS Summit 2021
146 min
Live e2e test debugging for a distributed serverless application
In this workshop, we will be building a testing environment for a pre-built application, then we will write and automate end-to-end tests for our serverless application. And in the final step, we will demonstrate how easy it is to understand the root cause of an erroneous test using distributed testing and how to debug it in our CI/CD pipeline with Thundra Foresight.
Table of contents:
- How to set up and test your cloud infrastructure
- How to write and automate end-to-end tests for your serverless workloads
- How to debug, trace, and troubleshot test failures with Thundra Foresight in your CI/CD pipelines

TestJS Summit - January, 2021TestJS Summit - January, 2021
127 min
Uniform Browser Automation Infrastructure
In this workshop, I will show you how to quickly deploy and use browser automation infrastructure with Moon solution. We will start deploying everything on your workstation and will soon be able to run Selenium, Playwright and Puppeteer tests in parallel in the same cluster. Then I will demonstrate how to easily deliver the same experience for your team using a remote cluster in the cloud platform.