Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
135 changes: 135 additions & 0 deletions src/assets/githubAction/runPlaywrightOnCI.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,135 @@
---
title: Playwright and GitHub Actions - Run tests in CI
authorName: Nabin Ale
authorAvatar : https://avatars.githubusercontent.com/u/61624650?v=4
authorLink: https://github.com/nabim777
createdAt: Apr 8, 2025
tags: continuous integration, continuous delivery, continuous deployment, github actions, ci, cd, playwright
banner: https://blog.jankaritech.com/src/assets/RunPlaywrightOnCI/images/githubaction_with_playwright_banner
---

This is a blog about how to run Playwright UI tests in GitHub Actions. If you are not familiar and new to UI testing using Playwright, then it would be good to check out this blog about [Playwright](https://blog.jankaritech.com/#/blog/E2E%20Testing%20using%20BDD%20with%20Playwright/Behavior%20Driven%20Development%20(BDD)%20using%20Playwright). Similarly, if you are unfamiliar with GitHub Actions, you can check another blog about [Introduction to GitHub Actions](https://blog.jankaritech.com/#/blog/Introduction%20to%20GitHub%20Actions%20-%20CI%20%26%20CD).

## 🤔 Why to run tests on CI?
Tests are run on CI(Continuous Integration) to ensure the code works properly in a clean and an isolated environment every time a change is made. Here are some reasons:

**1. Early bug detection:**
By automatically running tests after every code commit, you can quickly identify issues as they arise, preventing them from accumulating and causing larger problems later on.

**2. Fast feedback loop:**
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how is that different from point 1?

Developers get immediate notification for failing tests. That way they can fix bugs immediately and iterate quickly.

**3. Consistent testing environment:**
The CI servers run tests in an uniform environment. Therefore, there is no correlation between the developer configurations.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand that point.
correlation between what and what?


**4. Improved code quality:**
Regular running tests in CI ensures existing functionality does not become unusable if changes are made.
Comment on lines +25 to +26
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for me code quality and functionality are two different things.
Code quality is about having nice structured code, following formatting rules, principles like SOLID etc. Running UI tests in CI will not help with that.
Functionality can be achieved even with bad code quality (even harder and more difficult to maintain). UI tests will only check the functionality, not the code quality.


**5. Reduced integration issues:**
By regularly integrating and testing the code in CI, you reduce the risk of conflicts when merging large patches of code.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how does running the tests in CI help with merge conflicts?
Bob writes some code and adjusts tests => CI is green for him
Alice changes some code in a similar area and adjusts tests => CI is green for her
whoever merges first wins and the second one has to fix the merge-conflict. How does CI help with that?


**6. Automated process:**
CI systems enable developers to save time and effort testing things.

## 📘 About the Project

![Login page of the Project](/src/assets/githubAction/images/project_login_page.png "momo application")

In this blog, I have taken simple applications built using Vue.js. The GitHub repository is available at: https://github.com/nabim777/momo-restro-list.git

This is a basic application that includes login and logout functionality. E2E test is written using Playwright to verify the login feature.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there only one test or multiple?


## 🛠️ Running App Locally
Before setting up CI, let's run the application and tests locally.

**1. Install dependencies**

```bash
npm install
```

**2. Start the frontend and backend servers**


```bash
npm run serve # Start frontend
npm run backend # Start backend
```

## 🧪 Running UI Tests Locally

> **_NOTE:_** Make sure both the frontend and backend are running before running the tests.

To run the UI tests locally, use the following command:

```bash
npm run test:e2e tests
```



## ⚙️ Setting Up CI in GitHub Actions
After verifying the app locally, the next step is to set up CI using GitHub Actions. First, create a file named `ci.yml` in a project using the following folder structure:

```
📦momo-restro-list
┗ 📂.github
┃ ┣ 📂workflows
┃ ┃ ┗ 📜ci.yml
```

Then, add the following code in the `ci.yml`.

```yml
name: Run-project

on:
push:
branches:
- master
pull_request:
branches:
- master

jobs:
run-Restro-project:
runs-on: ubuntu-latest
steps:
- name: Checkout repo code
uses: actions/checkout@v3

- name: Set up node
uses: actions/setup-node@v3
with:
node-version: 20.x

- name: Run the project
run: |
npm run serve &
npm run backend &
Comment on lines +106 to +109
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- name: Run the project
run: |
npm run serve &
npm run backend &
- name: Install dependencies
run: npm install
- name: Run the project
run: |
npm run serve &
npm run backend &


- name: Wait for services
run: |
sudo apt-get install wait-for-it -y
wait-for-it -h localhost -p 8080 -t 10
wait-for-it -h localhost -p 3000 -t 10

- name: Install playwright and run web-ui tests
run: |
npx playwright install
npm run test:e2e tests
```


## 🔍 What this Workflow Does?
This GitHub Actions file runs when you push to the `master` branch or create a pull request to `master`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This GitHub Actions file runs when you push to the `master` branch or create a pull request to `master`
This GitHub Actions file runs when you push to the `master` branch or create a pull request to `master`.


It has one job called `run-Restro-project` with these steps:
1. **Checkout repo code** - Gets the project code from GitHub.
2. **Set up node** - Installs Node.js version 20.
3. **Run the project** - Starts the Vue app, and starts the backend using json-server.
4. **Wait for services** - Waits for the frontend (port 8080) and backend (port 3000) to be ready.
5. **Install playwright and run web-ui tests** - Installs Playwright and runs e2e tests to check if the UI works properly.

## 📝 Conclusion
Using GitHub Actions to run your Playwright UI tests ensures your app is always tested in a clean, repeatable environment. It helps catch bugs early, improves collaboration, and keeps your project in a healthy state.