Master passwordless authentication by writing end-to-end tests for passkey login flows using Playwright and enhance your web development skills today.

Exercise 03 (Solution)

[00:00] First, I will install a package called test passkey. I will use it to generate realistic passkeys for my end to end tests. What this package does, it generates a key pair consisting of a public key and a private key and returns two things. The first one being this credential object, this is the part of the passkey that gets stored in the browser, and then the public key which is the part that gets stored on the server. And I will use this package so I don't have to implement all of this in my own tests.

[00:27] To install that package, open your terminal and run npm install test dash passkey and provide a flag to install it as a dev dependency. Now I will head to the test file at test slash end to end slash authentication-passkeys.test.ts and complete this first test case. So first, I would need to create a test user. I would use the same function we used before, create user, and store it in a disposable object called user. Now I need to generate a test passkey and this is where the test passkey package comes in.

[01:00] So I will head here to the imports and import from test passkey package, the function called create test passkey. Then I will call that function over here, create test passkey and assign it result to a variable called passkey. This function requires a single argument, which is an object containing a key r p I d. This stands for relying party I d. And in a passkey, it represents a domain for which this key was issued.

[01:25] That is done for security considerations so you couldn't use this passkey on a different domain, for example, through phishing. So here we want to bind this passkey to our app And for that, we need to grab the current URL of our app and get it hold its host name by wrapping it in the URL constructor and grabbing the host name property. And because we're relying on the page URL, we need to have our app already open in the test before creating the task passkey. So I will head here and navigate to the login page. And by doing so, the created passkey will already be associated with the host name of our app.

[02:01] Now the next thing I want to do is create a record in the database that collocates this user and this passkey. To do this, I will use a utility called create passkey that I already have in my db slash utils. This utility is extremely similar to the ones we implemented before, like create user. And all it does is creates a record in the database using the Prisma client, returns that passkey, and also has this async dispose callback to delete the created passkey when the test is done. The important bit here is that it accepts the public key, which is a public part of the passkey, and also a user ID to associate that passkey with.

[02:38] So now I need to provide that data in the test. So here when I call this function, which returns a promise, I need to provide a bunch of things. Let's start from the public key, which we can get from the test passkey, dot public key. Then the ID of this passkey will be passkey dot credential dot credential ID. The user ID will be user dot ID, which is our test user.

[02:59] And the a a g u ID will be passkey credentials a a g u I d or an empty string if it's not set. And now because this create passkey utility returns a disposable object, I will consume it appropriately by calling await using and using underscore as the name because once again, I don't need the return database entry in this test. And now I will log in using a passkey in the UI by locating the button by role page role button and its accessible name. Log in with a passkey and I will click that button to initiate this login flow. And as the expectation, once again, I want to make sure that the user profile link is visible in the UI, confirming that the login was successful.

[03:42] Now there's just one thing missing from this equation. So we created the user and created a passkey for our app and created the entry in the server associating the user and the public part of this passkey and what's missing is storing that passkey in the browser because passkeys are stored on the device and we can use Playwright's API to do that. Adding a passkey to the browser will consist of two steps. First, adding your web authentication client and then adding our passkey to that client so the browser can use it. I will head to the top of this file and create a new utility which will be an asynchronous function, called create web authentication client.

[04:20] This utility will accept a Playwright page of the type page from Playwright, and then I will call page dot context to get the browser context and the new c d p session method there. Calling this method creates a new session in Chrome DevTools protocol. This is a special protocol that Playwright itself uses to communicate with Chrome and automate it. We will use this protocol to register a new virtual authenticator that will use our passkeys. So it's an asynchronous method, and we will store the result of it method in a variable called session.

[04:50] Now I will call session dot send web authon enable and await this promise. Sending this argument to the CDP session will enable web authentication. Next, I will create a virtual authenticator by calling session dot send with this argument which is web authentication dot add virtual authenticator. And I will use the following options. The important one here is the last one, automatic presence simulation, set to true.

[05:17] By setting this option to true, playwright will automatically select the first evaluable passkey from the list of passkeys, which is exactly what we need. I will store this virtual authenticator in a variable called authenticator. And from this entire utility, I will return two things which is our CDP session and the authenticator ID, which is authenticator authenticator ID. And the only thing left to do now is to add the test passkey to this authenticator. So I'll head back to my test.

[05:48] After I created this passkey record, I will call await create web auth and client, my utility, provide the page as an argument, and here I will destructure this return object to grab the session and the authenticator ID. And now to add the pass key to this authenticator, I will call await session dot send and provide it this argument web authentication dot add credential. And I will describe what kind of credential I want to add in the second argument which is the options. Here, I'm telling the CDP session to add this credential to this virtual authenticator by ID and this is the credential itself. Here, I'm referencing my test passkey and spreading its credential object including the username from my test user, user handle is the user ID encrypted in base 64, and also the user display name if they have one.

[06:36] If not, it will be an email. And now this concludes the setup for this test. So let's recap quickly. We created a test user like before. We went to the login page, so our application is already open in playwright.

[06:48] We created a test pass key binding it to our host name, to the host name of our app, and then we created the server side record in the database connecting the pass key, its public part, with our user ID. And finally, we used the virtual authenticator to add this passkey as a credential object for our test. Now let's run the test to see if it's passing. So in the terminal npm run test end to end. I can see that there's an error with the test, and if I scroll up, I can see why it's failing.

[07:18] Playwright is complaining that I was expected to pass a page or a frame to this new CDP session method. So let's scroll up to this utility, and here, even TypeScript is warning us. So let's add page here as an argument. This is the same page that we passed as an argument in the test over here. Now that I have this fixed and the CTP session should be created correctly, let's run the tests again, npm run test end to end, and now hopefully they will pass.

[07:46] That's exactly what's happening. If you scroll to the server logs, you can see that we're hitting the web authentication methods because we're using passkey as the authentication. And naturally, all the steps that we are describing from adding the passkey and to choosing the proper login method are passing including our expectations to be signed in. Let me draw your attention to how our test looks like. So here are the lines that we spent automating the browser and acting as the user on the page and all of these lines are part of our test setup.

[08:16] You can see how much effort we spend arranging all these pieces just to have a simple test afterward. And this is the right way to approach complexity in tests. Because this scenario is moderately complex, and one of the common mistakes developers make is they rush in head on into the test juggling all the pieces together instead of approaching it methodically. Understand what moving pieces you have in your test case. Where is the main root of the complexity here?

[08:42] Like in our case, it was to understand that the passkey will be stored on the device and also on the server, so we arranged those setup steps in order to have a simple test afterward, which is just one action followed by a single assertion. And I will finish by adding another test case that makes sure that our app displays an error by authenticating via a passkey fails. So here I will still need our navigate fixture and the page fixture. To reproduce this scenario, I don't really need a test user so I will head straight to the login page. And now I still need to tell Playwright that the user has no passkey selected or in other words user is not verified to use passkeys.

[09:31] If I don't do this and try to go through the normal logging flow, I will get an error message from Playwright that this authentication method is not configured. This is not an error that the actual user would get. So to do that, I will use our create webauthin client for this page. I'll grab back the Session and our Authenticator ID and I will call await session send and I will send this command set user verified That is bound to this authenticator ID and has the is user verified property set to false. By doing this, I'm letting Playwright know that I'm simulating the scenario when the user either doesn't have pass keys or hasn't selected any during the login flow.

[10:15] And from here on out, let's just repeat the same steps. Gonna click on the button, log in with a passkey, but my expectation here will be different. I'm expecting to see an error message. So I expect a page element by role alert to have the following error message visible on the page. So in other words, when we're trying to go through this scenario, we navigate into the login page, we're letting the playwright know that there are no passkeys configured for this user, or the user hasn't selected any passkeys.

[10:45] And when they try to go through this logging flow, they will see the following error message that the application failed to authenticate them using a passkey. Now let's run both of these scenarios to make sure that they're passing. PM run, test, and to end. And now we've got both of them covered. I cannot stress the importance of the test setup enough when it comes to end to end tests because you have this big complex thing on your hands which is your app and the proper way to address all of that complexity is in the setup.

[11:16] So make sure to invest enough effort in writing those utilities, into understanding every test case, what it entails, and what makes it complex. Because once you have those setup blocks implemented and ready, every test case becomes a matter of combining them together and acting as the user would.

Passkeys

[00:00] Another way the users can log in into our app is by using their passkey. A passkey is a type of passwordless authentication that often uses biometric data, gets stored on the user's device, and is really secure. Here's how it looks like in practice. On the login page, the user can scroll down and choose this login with a passkey option. Once they do, they will be presented with this pop up that will list all the passkeys they have suitable for our app.

[00:26] I don't have any registered right now, so there's nothing to choose from. But the users who do will be able to click on their passkey and successfully log in. In this exercise, your task will be to write an end to end test for the authentication flow that uses a passkey. Similarly to the two factor authentication, a public part of the passkey will be stored in the database, so make sure to provision that as a part of your test setup. You will use a third party library to help you generate viable passkeys, and also some built in APIs in Playwright to prompt this passkey selection in the browser.

[00:58] So give it your best and see you once you're done.

Do you know this feeling when you finally trust your tests? When running them no longer makes you brace for impact, but instead gives you the confidence to ship without second-guessing every deploy. End-to-end tests rarely earn that trust. They've earned a reputation for being expensive, slow, and unreliable, and most of the time, that reputation is deserved.

Today, I want to change that for you with Playwright.

In this workshop, my goal is to make you rethink what end-to-end testing can be. That means stepping beyond the cargo-culted patterns that gave E2E tests their bad reputation in the first place. That means getting so good at Playwright that you would feel confident writing tests that are meaningful and performant, and, dare I say, a pleasure to maintain.

Welcome to the Playwright workshop!

## What You'll Learn

End-to-end tests can get really complex really fast. I will teach you how to deal with that complexity by making intentional choices throughout the workshop: from configuring Playwright to arranging your test setup to reduce flakiness and get the test suite that you can trust.

On top of that, you will be crafting your own test experience through custom fixtures, disposable test data, and reproducible authentication snapshots. This will help you orchestrate tests for complex, real-world applications.

### Fundamentals

In the first block, you will get comfortable with Playwright. From installing it and covering the essential configuration options for a great testing experience both locally and on CI, to getting familiar with the test structure, the `page` object, and why it gives you element *locators* instead of direct DOM references. You will wrap up by writing your own custom fixture for type-safe page navigation in your end-to-end tests.

### Authentication

You will learn the difference between testing authentication as a feature and testing features that are *behind* authentication. Yes, those require entirely different approaches. Then, you will write tests for the most common authentication methods in web applications. With **basic auth**, you will create a disposable `createUser()` utility that creates a test user in the database and deletes it when the test is done. With **two-factor authentication**, you will create test OTP tokens and store their verification records in the database for your test user. And with **passkeys**, you will leverage a Chrome Developer Protocol session to create a web authentication client with the passkey you provide and use it in your test.

After that, you will explore how to create and manage authentication in your test setup using [Personas](https://github.com/kettanaito/playwright-persona), reproducible snapshots of different authentication states that bridge the DX gap of `setStorageState` in Playwright.

### Guides

Next, you will dive straight into practical tips for writing end-to-end tests: from provisioning mock databases and test data to mocking client-side requests. As a bonus, I will show you how to write tests by recording your interactions in the browser using Playwright's extension for Visual Studio Code.

### Debugging

And yes, I've saved the best for last. Debugging.

It's become somewhat of a tradition to include debugging techniques in my workshops, and this one will be no different. You will master the UI mode to preview and debug your tests *visually*, and after that, learn how to debug failed CI tests with the Trace Viewer. **This is, seriously, such a time-saver.** No more guessing why a test failed three commits ago on a machine you don't have access to. You will have the entire test run at your fingertips.

## Who Is This Workshop For

This workshop is for any developer who wants to write end-to-end tests they can actually rely on. For everyone who has watched a CI pipeline turn red because of a flaky test that passes locally. For everyone who has been told that end-to-end tests are inherently slow and unreliable, and refused to accept that as the answer.

You don't need prior Playwright experience to get the most out of these exercises, but a working familiarity with modern web applications and a healthy skepticism toward the current state of E2E testing will serve you well.

Master Playwright end-to-end testing: setup, authentication (basic, 2FA, passkeys), mocking, fixtures, and debugging with UI mode and Trace Viewer.

React End-to-End Testing with Playwright

Artem Zakharchenko

Writing tests for their own sake is a pointless chore:

```tsx
describe('add numbers', () => {
  it('should add two numbers', () => {
    expect(add(1, 2)).toBe(3)
  })

  it('should add two other numbers', () => {
    expect(add(3, 4)).toBe(7)
  })
});
```

Another annoying testing problem is when tests are too brittle, and paint your logs red even though the application seems to work just fine.

When your tests lack real purpose or seem to fail for no good reason, it's no wonder you start to question their value.

Tests are supposed to give you confidence in your code, and save you from shipping broken stuff to prod. So why does writing them feel like such a burden?

The problem is that tests like these are focused on implementation details instead of the underlying behavior. Everyone talks about the importance of testing, but there's a lack of understanding about how to write tests that are actually useful.

How would it feel to have 100% trust in your tests, knowing that any failures are not a false alarm? What if you could seamlessly translate the underlying behavior of your application into tests that are easy (and even fun) to write?

It's possible, but it requires you to take a step back from just syntax.

In order to have the confidence you're testing the right things in the right ways, you need to dig into the underlying patterns behind the scenes of a testing framework.

This is exactly what you will do in Testing Fundamentals.

In this workshop, Artem Zakharchenko, testing expert and creator of the Mock Service Worker API mocking library, will guide you through creating your own version of the Vitest testing framework.

Building a testing framework from scratch will give you a deep understanding of how the pieces fit together, and change the way you think about testing for the better.

## What You'll Learn

The workshop is broken out into four parts, each with its own challenges and exercises that build upon the last:

### Principles

First, you'll explore the principles and mental models that underlie testing strategies. This is where you will begin to distinguish between the intention of your code and its implementation details. When you focus the intention of what your code should accomplish, you can write tests that are more resilient to change.

### Test Structure

Next, you'll do a deep dive into the structure of the testing framework. You'll create your own `expect` and `test` functions, configure your test environment, and use hooks to manage side effects in your tests.

### Testing Asynchronous Code

Testing asynchronous code requires a slightly different approach when compared to testing synchronous code. Here you'll practice with testing promises and async functions, as well as handling errors and rejections.

### Moving to Vitest

Once you've learned the fundamentals of testing and built your own mini-framework, you will migrate your tests to the Vitest framework. This process will cement your understanding of not just the "hows", but also the "whys" of testing.

## Who This Workshop Is For

This workshop is for developers who have some testing experience, but feel like they're missing the bigger picture. If you're tired of writing tests that feel like a chore, and want to understand how to write tests that are actually useful, this workshop is for you.

Testing Fundamentals

Let’s face it, mocking can be really confusing.

First, you need to know what to mock. Then, find the right way to mock that thing so it doesn’t compromise your test suite. Over-mock, and your tests become pointless. Under-mock, and they get brittle instead.

In either case, you put in so much effort, and you don’t feel like you’re getting much in return.

This is where Artem comes in. He’s been proving developer misconceptions around mocking wrong for nearly a decade, and he’s here to make you a mocking pro.

## What You’ll Learn

In this hands-on workshop, you’ll learn:

- The purpose of mocking;
- What to mock and when;
- How to write mocks that bring value instead of being a maintenance chore;
- How to separate your mocks from implementation details;
- Type safety strategies for your mocks;
- And **all the mocking techniques** you will need to test your code!

By solving targeted, real-world problems using the Vitest framework, you’ll gain a comprehensive understanding of mocking and finally unlock it as a useful tool in your testing arsenal.

## Workshop Structure

This workshop contains 6 exercise blocks dedicated to various techniques on mocking different data types.

### Boundaries

Understand what mocking really is, and learn how it helps you create test boundaries. See what each mock you introduce does to your tested code using visual metaphors.

### Mocking Functions

Functions are at the heart of JavaScript logic. Learn how to mock functions for effective input-output testing. Create mock functions, spy on function calls, and mock function implementation to tap into the right behaviors of the tested code.

### Mocking Date and Time

Eliminate the side effects of ever-changing date and time in your tests. Learn how to freeze time and mock date/time-dependent code to ensure consistent test results across different runs and time zones.

### Mocking Globals

Explore how to mock implicit dependencies, in a non-intrusive way. Learn to mock global values, methods, and environment variables to create the perfect test setup without meddling with things you don't own.

### Mocking Network

Gain control over network communication and test your client-side code reliably. Intercept requests and mock responses using Mock Service Worker. Reproduce various network scenarios, from success and error responses to offline behavior and response timing.

### Mocking Modules

Understand when to use module mocking and explore alternative techniques before you do. Learn how to mock modules in a type-safe and efficient way using built-in APIs in Vitest.

## Who This Workshop Is For

This workshop is meant for all developers, both those who are new to automated testing and those who’ve been writing tests for years. If you are unsure when to introduce mocks into your test suite, or how to do that so you don’t have to refactor it the next day, this workshop was made specifically for you.

Mocking Techniques in Vitest

The closer your tests resemble how your software is being used, the more confidence they will give you. There’s so many great patterns stemming from this simple rule, patterns I’m sure you’re already using to write better tests.

Then, there’s the elephant in the room. **Your test environment.**

For decades, web developers have been testing their UIs in make-believe environments that are neither the browser nor Node.js. It made them come up with a frankly ridiculous amount of test setup, polyfills, and workarounds just to make it work. Remember when you had to mock `location` in tests? `window.matchMedia`? Yeah…

It’s time to abandon such practices. The tools have improved and there’s no excuse for you to be sleeping on it. It’s time for you to learn how to use Vitest Browser Mode for in-browser component testing!

## What You’ll Learn

In this workshop, you will learn a new approach to component testing that’s both different and the same. It is different because you will write and run your tests in the actual browser, taking advantage of the standard APIs and powerful browser automation. It is the same because it’s still the component level test you know and love, with rendering, querying, and asserting. 

Your users don’t interact with the UIs you build in JSDOM. They do that in the real browser, and now your tests will too!

### **Sunsetting JSDOM**

The first step in our journey is understanding why browser-like environments fall short. JSDOM has served us well, but it's time to recognize its limitations. You'll experience firsthand how browser-like environments like JSDOM are letting you down.

We'll explore examples of valid JavaScript code that works perfectly in browsers and Node.js but fails in JSDOM, undermining the value of the tests you work so hard to write. You'll discover why these inconsistencies happen and why moving to real browser testing is the solution.

### **Vitest Browser Mode**

Vitest Browser Mode allows you to run isolated component-level tests in the actual browser while providing the convenience and flexibility of integration-level testing. It's not a full end-to-end testing framework like Playwright or Cypress, but rather the perfect middle ground for component testing.

In this module, you'll learn:

- How to install and configure Vitest Browser Mode in your project;
- The technical differences between how JSDOM and Browser Mode run your tests;
- Steps needed to migrate existing JSDOM tests to Browser Mode;
- How to set up Playwright as the browser automation provider for your component tests;
- Common setup scenarios like applying global assets in tests and configuring Vitest for both unit and component-level testing within the same project.

### **Best Practices**

Choosing the right tools is important, but knowledge that transcends any particular tool is even more valuable. In this section, we'll focus on five key areas of best practices when it comes to testing your React components:

- **Queries**: Find elements on the page the same way your users or their assistive technology would;
- **User events**: Interact with the tested elements from the user’s perspective;
- **API mocking**: Use Mock Service Worker to intercept requests and handle their responses as well as discover how to efficiently use MSW in Vitest Browser Mode by creating a custom test context;
- **Element presence**: Test elements that should (or shouldn't) appear on the page reliably without false positives or flaky results.
- **Page navigation**: Learn where to draw the line when testing page transitions and routing in the actual browser.

### **Debugging Tests**

The true value of tests comes when they fail. But dealing with failing tests can be quite frustrating without the right techniques.

In this block, you'll learn some of my favorite debugging techniques that go well beyond console logging:

- How to inspect the DOM state at any point in test;
- Using the debugger statement to stop JavaScript execution entirely;
- Wielding conditional breakpoints to step through the problematic code.

These techniques will transform your approach to test failures from dread to confidence so the next time you see a failing test you will know what to do.

## Who Is This Workshop For

This workshop is for all React developers who want to write reliable and valuable tests for their components. Whether you're new to component testing or have been writing tests for years, you will inevitably learn new tools, APIs, and techniques to gain more value out of your test suite. That’s my sole motivation behind this material.

React Component Testing with Vitest

Do you know this feeling when a tool “clicks”? When you suddenly become so comfortable with it that it’s no longer just a means to an end but an instrument to craft better experiences for yourself. Over the past decade, that transition has happened with a bunch of tools for me.

Today, I want it to happen for you with Vitest.

In this workshop, my goal is to make you a Vitest superuser. And that means stepping beyond the basics and into the advanced. That means getting so good at Vitest that you would feel confident crafting custom test experiences, understanding the inner works of your test runner, and equipping that knowledge to solve everything from complexity issues to poor test performance.

Welcome to the Advanced Vitest Patterns workshop!

## What You’ll Learn

The overarching theme of this workshop is ***customization***. I believe your experience with tools is defined by how well you understand them and how comfortable you are when it comes to customizing them. With this workshop, I’ve collected some of the best techniques and pieces of advice to make you a true Vitest superuser.

I’m also taking this workshop as an opportunity to teach you the importance of the test setup. Throughout the exercises, you will be crafting your own test experience through things like custom fixtures, matchers, and equality testers. This will help you orchestrate tests for complex, real-world applications.

### Setup

In the first block, you will get more comfortable with Vitest. From writing and debugging tests faster with the Vitest’s extension for Visual Studio Code, to configuring and visually exploring code coverage and setting up multiple test projects to use your test runner to the fullest.

### Context

You will learn how to customize your test experience by creating *custom fixtures*. Discover the fixture syntax, its life-cycle, and how to implement them in a type-safe way. Then, note down the best practices of fixture design to make sure your custom fixtures eradicate complexity, not introduce it.

### Assertions

Following the topic of customization, find out how you can supercharge your assertions. First, you will create your own matchers to help express your expectations toward your tested app and make your tests read like human language. Then, explore what is an equality tester and how you can teach the Vitest’s built-in `.toEqual` matcher to compare the incomparable.

Nail down how to write assertions for eventual states with `expect.poll` and become in full control of how much information you get out of failed assertions by understanding the balance between the hard and soft assertions.

### Performance

And yes, I’ve saved the best for last. Performance.

Learn how to profile slow test runs using built-in metrics in Vitest as well as the `vitest-profiler-plugin`. You will read the CPU and heap profiles, understand what they mean, and how you can use them to hunt down the problematic areas of your tests.

Everything past this point is techniques to make your tests faster. **We are talking up to x40 times faster** (that’s not a typo). Take a peek behind the scenes to see how Vitest orchestrates test runs and what defaults it has in place to ensure reliable results. Go through the difference between parallelization and concurrency in tests, explore the effects test isolation has on performance, and learn how to split your tests into shards for faster CI/CD jobs.

## Who Is This Workshop For

This workshop is for all developers who want to learn how to customize Vitest to create better, custom test experiences on top of it. For everyone who has felt like adding a new test in your project feels like fighting against the entire world. For everyone who has found themselves lost before a slow test suite.

As the name suggests, you will be going through advanced topics, which makes a prior basic experience with Vitest mandatory to get the most out of these exercises.

Advanced Vitest Patterns 

The Testing Bundle

Master Playwright for efficient end-to-end testing, covering setup, authentication, and debugging to enhance your web app's reliability.

React End-to-End Testing with Playwright Introduction

Workshop Introduction

Master end-to-end testing for web applications and ensure quality from UI to backend, using effective strategies to simulate real user scenarios.

Fundamentals Intro

Master end-to-end testing with Playwright by installing dependencies, configuring settings, and writing your first test to enhance your web development skills.

Exercise 01 (Solution)

Install & configure

Refactor your Playwright configuration to run the Epic Notes app in tests. Enhance your end-to-end testing skills and ensure your app functions flawlessly.

Exercise 02 (Solution)

Running the app

Enhance your Playwright tests with type-safe routing. Implement a custom fixture to avoid navigation errors and streamline your end-to-end testing process.

Custom fixtures

Master Playwright by installing, configuring, and implementing custom fixtures, then prepare for essential authentication testing in your app.

Fundamentals Outro

Fundamentals

Master end-to-end testing by effectively handling authentication as both a feature and a dependency, ensuring robust app functionality and user experience.

Authentication Intro

Master username and password authentication by creating a test user and implementing successful and failed login test cases to ensure robust functionality.

Basic

Master two-factor authentication testing by implementing OTP code verification. Enhance security in your app while building effective test cases with ease.

Two-factor authentication

Master testing user behaviors behind authentication by managing notes in your app. Enhance your skills with practical, hands-on exercises.

Exercise 04 (Solution)

Protected logic

Master efficient authentication testing and enhance your end-to-end tests. Unlock the secrets to robust application security with Item 99.

Authentication Outro

Authentication

Master end-to-end testing by enhancing your setup with best practices, efficient test data management, and user-centric approaches for reliable results.

Guides Introduction

Enhance your testing strategy by isolating your test database. Set up a dedicated test environment with Playwright for reliable end-to-end testing.

Mock database

Master note management by testing user authentication and data handling. Prepare and clean test data to ensure seamless functionality in your application.

Test data

Master end-to-end testing by using Playwright to automate changing a user's name in an app. Enhance your skills and streamline your testing workflow!

Recording tests

Master API mocking with Playwright to ensure reliable end-to-end tests by intercepting third-party requests and creating stable test environments.

API mocking

Master debugging techniques in end-to-end testing and enhance your development skills. Dive into practical exercises and elevate your problem-solving abilities!

Guides Outro

Guides

Master debugging end-to-end tests with Playwright. Gain insights into test failures and enhance your app's reliability through effective strategies.

Debugging Introduction

Debug and fix a failing test case in Playwright by using UI mode to visually trace actions and ensure user nodes appear correctly.

UI mode

Master debugging with Playwright's Trace Viewer to analyze a failed test run, identify issues, and enhance your testing efficiency. Fix it now!

Trace viewer

Master essential debugging in Playwright with UI mode, Trace Viewer, and more. Enhance your testing skills and troubleshoot like a pro!

Debugging Outro

Debugging

Master Playwright for comprehensive web app testing and enhance your skills with effective end-to-end user journey tests. Stay safe and test smart!

React End-to-End Testing with Playwright

React End-to-End Testing with Playwright

Transcript

Passkeys

Transcript