Writing end-to-end (e2e) tests don't need to be hard. Playwright provides a smooth - in my opinion, the best - developer experience, which makes it straightforward to go from nothing to your first e2e test.
You will probably see me putting more content out on playwright, because I'm so enthusiastic about this tool. For now, let's start at the beginning, and let's take a look at the required steps to have your first e2e test in place. This only takes a few minutes!
Of course, the first step is to install playwright.
You can do this manually or you can make it easier by running the
npm init playwright command, this also creates a config file in your project.
Included in the generated config, you see the default values of popular options with a link to the docs. This makes it easier to find information about the configuration. While the config speaks for itself, I like to highlight a few points that make me happy.
- forbidOnly: if enabled, the CI throws when there's a focused test (
- retries: on a failure, retry the test N amount of times
- workers: faster test execution because test cases are run in parallel (multiple tests are run at the same time)
- trace: persist test info (screenshots, video, logs) on a failure
- projects: run test cases in multiple environments (browsers, screen sizes, emulations, ...)
Besides the above config file, an example test file is also added to the project.
Did you notice that the title is "creating a test" and not "writing a test"? This is because playwright comes with a test generator that writes the test specification for you, you only need to interact with the application.
To create your first time, make sure that the application is running and then run the
playwright codegen command.
This opens up a browser window, and also the playwright inspector GUI tool. When you start to interact with the opened browser, you can see that the inspector writes out the test code for you.
Close the browser window when you're done and the test is included in the project. As an example, let's take a look at the following test, which is the result of the above GIF.
If you ask me, this is a pretty good test. The element selectors don't rely on css selectors nor on ID selectors. This is good because it makes sure that the test code is robust to future changes, and the flow is easy to understand.
The test case is already good, but I'd still like to make a few small changes to make it more compact:
- give the test case a better description name
- remove the hard coded URL
localhost:4200(more on this later)
- remove the comments
- remove a few redirects because these are made by the application
- remove unnecessary clicks, e.g. simply type in an input field instead of first clicking in the element before typing in it
typebecause of the implementation of the autocomplete input
Now, the refactored test looks like this.
The last change is a change to the configuration file.
webServer config, and set the start and port options that are applicable to your project.
I also like to enable the
reuseExistingServer option so that it doesn't start a new application when it's already running.
Now, playwright runs the application when you run the
npx playwright test command if it isn't served already.
Resulting in the following output. As you can see below, the test is executed twice. This is because there are two projects defined in the configuration, one for chromium, the other one for firefox.
And ta-daaa, here's your first playwright test. Nice and simple!
Integrating playwright in your project is straightforward with the
npm init playwright command.
You can use the
playwright codegen command to generate the test flows while you interact with the application, as a real user would.
While the test looks good and is robust, it's desirable to make a few tweaks to improve the test and make it more compact.
I appreciate it if you would support me if have you enjoyed this post and found it useful, thank you in advance.