GithubHelp home page GithubHelp logo

kawqa-gad-playwright's Introduction

Playwright Tests for GAD application

Installation and setup

Prerequisites

Test Repository Setup

Please check information in our contribution guidelines

Running Tests

  • to run all tests: npx playwright test
  • to run a specific test: npx playwright test {testfilename.ts}

kawqa-gad-playwright's People

Contributors

bugitwhisperer avatar kat-kan avatar adamcegielka avatar karolinazakrzewska avatar justyna-ko avatar slawomir-dkl avatar

Stargazers

avatar avatar

Watchers

avatar Freudenberger avatar avatar avatar avatar

kawqa-gad-playwright's Issues

[GitHub Project] auto-trigger tests run on CI before merging changes to the base branch (`main`)

✏️ Description

Auto-trigger test-runner job on Github Actions CI before merging changes to the base branch (main).

🔧 Why We Need This

We will ensure that our changes do not result in breaking tests.

🚀 Proposed Solution

as per description in jaktestowac course:
https://jaktestowac.pl/course/ciagla-integracja-i-testy-automatyczne-z-playwright-i-github-actions/

✅ Issue reporting checklist

  • I created a descriptive title for this issue
  • I checked that it hasn't been reported yet
  • I assigned the issue or added help-wanted label
  • I added appropriate labels

[GitHub Project] Configure adding labels to issue based on its type

✏️ Description

Idea from one of our meetings: there are 3 types of issues and some of labels could be assigned automatically
https://docs.github.com/en/actions/managing-issues-and-pull-requests/adding-labels-to-issues

🔧 Why We Need This

To automate adding labels

🚀 Proposed Solution

Explore on possibilities, discuss with the team and implement

✅ Issue reporting checklist

  • I created a descriptive title for this issue
  • I checked that it hasn't been reported yet
  • I assigned the issue or added help-wanted label
  • I added appropriate labels

[Documentation] README fix

update README.md file
replace somewhat confusing step:
copy application main URL as value of BASE_URL variable in .env file
with the below one:
copy ".env-template" file and change its name to .env

[CONFIG] [LIB] add Winston logger lib to the project

As per suggestion in one of the PR threads here, if we want to have logging actions in the project, it makes sense to install Winston library for that: https://www.kimsereylam.com/typescript/2021/12/03/winston-logger-with-typescript.html

References:

PATCH/ comments - add more test cases

Completing patch-comments tests with other possible API answers for this endpoint, listed in the GAD application documentation.

✏️ Description

-add test: 401Unauthorized -> when invalid token is sent in headers

-add test: 400 Bad Request -> when malformed json is used

-add test: 422 Unprocessable Entity -> when keys are missing and values are too long

-add test 404 Comment not found

  • I created a descriptive title for this issue
  • I checked that it hasn't been reported yet
  • I assigned the issue or added help-wanted label
  • I added appropriate labels

[CI/CD] Investigate failing tests

✏️ Description

Current automatic checks while pushing/creating pull requests are failing due to 2 tests:
POST articles
POST comments

🚀 Expected Behavior

There should be no issue with automatic checks

🛑 Current Behavior

Example failure: https://github.com/kat-kan/kawqa-gad-playwright/actions/runs/8364416857/job/22899713219?pr=81

🔁 Steps to Reproduce

📷 Screenshots or Additional Information

✅ Problem report checklist

  • I created a descriptive title for this problem report
  • I checked that a similar issue hasn't been reported yet
  • I assigned the problem report or added appropriate labels

[CI/CD Pipeline] Use secrets to store sensitive information: BASE_URL, USER_EMAIL, USER_PASSWORD in workflow

✏️ Description

Currently, the sensitive information such as app's URL and test user's credentials are directly visible in the workflow file instead of being protected. As discussed in our last meeting, it'd be best to use secrets to protect those.

🔧 Why We Need This

Using secrets in CI/CD pipeline is a good practice, because it:

  • does not rely on data that's directly hardcoded lowering the risk of exposure,
  • ensures tests are being executed securely,
  • makes them available/accessible to the selected group of users only -> meaning us, members of the KawQA-z-automatu initiative! :)

🚀 Proposed Solution

TBA

✅ Issue reporting checklist

  • [x ] I created a descriptive title for this issue
  • I checked that it hasn't been reported yet
  • I assigned the issue or added help-wanted label
  • I added appropriate labels

Branch naming standards

Challenge

It'd be great if we would use the same branch naming convention throughout the project, like it's done in real-life scenarios.

Proposed Solution

Use husky library and npm package validate-branch-name to create pre-commit hook that would require changing branch name to the one that's following expected naming convention - reference:

Given user created feature-branch name `tests-new-test-added`
When user tries to commit their changes
Then there's an error msg displayed:  `Branch name validation failed! Please rename your current feature-branch`
And changes won't go through

[Config][Bug?] Explore existing Husky hook with git ammend

This is a low priority, but I want to have it written down somewhere.
I was working on branch with correct name (tests/ISSUE-21_add_post_articles_test) and I wanted to edit message for one of the commits.
I was blocked by Husky validation even though the commit was previously accepted and I was on the same branch.

Scope of the issue:

  • test git amend with our Husky config
  • if bug confirmed, look for solution or at least create a new issue for it.

Playwright - init config

Description

  • git init - initialization of git required
  • Playwright init - test framework default config required

Fix POST article test after adding validation for date

✏️ Description

In release 2.5.4 validation for date was added and one of tests is failing
https://github.com/jaktestowac/gad-gui-api-demo/releases/tag/v2.5.4

🚀 Expected Behavior

🛑 Current Behavior

🔁 Steps to Reproduce

📷 Screenshots or Additional Information

✅ Problem report checklist

  • I created a descriptive title for this problem report
  • I checked that a similar issue hasn't been reported yet
  • I assigned the problem report or added appropriate labels

[Discussion/Group Decision] API checks prioritization

Challenge

Currently, we don't have any priorities as to which endpoints automate first - what is our overall testing strategy?

  • API checks prioritization and strategy - to be discussed during KawQA-z-automatu meeting on Monday, 30th of Oct 2023 Monday, 27th of Nov ;)

[Project Config] install ESLint lib for static code analysis

✏️ Description

Install ESLint library to help with enforcing consistent coding practices

🔧 Why We Need This

Alongside the already installed Prettier lib, it will be a great tool for static code analysis that finds any code issues

🚀 Proposed Solution

✅ Issue reporting checklist

  • I created a descriptive title for this issue
  • I checked that it hasn't been reported yet
  • I assigned the issue or added help-wanted label
  • I added appropriate labels

POST /login - tests

Challenge

Write tests for Login endpoint

Solution

  1. add dotenv library - following the best practices, it's worth to use dotenv library so that login credentials are not "visible" in the code, but kept locally
  2. remove unnecessary comments from the pw config file, update the playwright.config.ts
  3. add scripts to package.json, so that we can use our personalized commands for running tests

[Test support] add enum with status codes that are currently in use

Challenge

We have identified a repetition in our code where variables are used to store the expected status codes for assertions.

Solution

Since we decided not to use any external library that would include the list of status codes, having an enum with a list of status code currently used will come in handy.

Add GET comments test

✏️ Description

Add tests for GET/comments

🔧 Why We Need This

NA

🚀 Proposed Solution

NA

✅ Issue reporting checklist

  • I created a descriptive title for this issue
  • I checked that it hasn't been reported yet
  • I assigned the issue or added help-wanted label
  • I added appropriate labels

[GitHub Project] enable 1) branch auto-deletion 2) feature-branch merge auto-prevention

✏️ Description

Enable 3 below settings in our GitHub Project:

(1) branch auto-deletion after branch is merged -> info and solution below:
https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-the-automatic-deletion-of-branches

  1. Go to Settings > General: section "Pull Requests"
  2. select Automatically delete head branches

(2) prevention from merging feature-branch if there are:
(2.1) outstanding changes on main -> info and solution below:

  1. Go to Settings > General: section "Pull Requests"
  2. select Always suggest updating pull request branches

(2.2) any unresolved conversations -> info and solution below:

  1. Go to Settings > Branches
  2. Check the field: Require conversation resolution before merging

(3) prevention from merging directly to main w/out raising PR - info and solution below:

  1. Go to Settings > Branches
  2. Click Add rule on Branch protection rules
  3. Add main as the Branch name pattern
  4. Require pull request reviews before merging
    -Required approving reviews: 1

🔧 Why We Need This

To prevent issues/bugs :)

✅ Issue reporting checklist

  • I created a descriptive title for this issue
  • I checked that it hasn't been reported yet
  • I assigned the issue or added help-wanted label
  • I added appropriate labels

Fix broken POST tests for GAD Version: v2.5.3

✏️ Description

After updating to version: v2.5.3 of GAD POST tests are broken

🚀 Expected Behavior

Working tests

🛑 Current Behavior

Two tests broken:
POST articles tests › Returns 401 Unauthorized after sending article JSON with missing userId
POST articles tests › Returns 201 Created after creating article

🔁 Steps to Reproduce

📷 Screenshots or Additional Information

✅ Problem report checklist

  • I created a descriptive title for this problem report
  • I checked that a similar issue hasn't been reported yet
  • I assigned the problem report or added appropriate labels

[DOCS] - Add explanations to README.md and CONTRIBUTING.md

✏️ Description

I propose adding some explanations for less obvious parts of the README and CONTRIBUTING documents

🔧 Why We Need This

As a relatively new user of Playwright, I'd like to know why e.g. vscode-icons is recommended as an optional plugin to install. Also, some steps in contributing guidelines are not clear to me.

Of course, I can do all the edits, but I would need some explanations.

🚀 Proposed Correction or Addition

Contributing.md:

  1. Add an explanation of the "with-deps chromium" option. I don't understand, why I should add this command. If it is decided to skip testing on Firefox and Webkit, please add this information, too.
  2. Explain what e-mail and password are needed in the .env file and how to obtain the data (for users starting work in GAD)

Readme.md:

  1. Explain what every plugin does (if it is not obvious) or why it is recommended in the project. A nice and short explanation is in the case of Thunder Client - for making quick API requests within VS Code. Some of the plugins are obvious to me, but some (e.g. vscode-icons) are not.

It would be useful to write some troubleshooting (e.g. as the last part of Readme.md) - what to do if in the initial test run you got a lot of 401 etc.

✅ Documentation fix checklist

  • I created a descriptive title for this documentation fix
  • I checked that a similar documentation issue hasn't been reported yet
  • I assigned the issue or added help-wanted label
  • I assigned the documentation fix or added appropriate labels

Add tests for GET/article-labels/articles

✏️ Description

This is pretty self-explanatory, add tests for successful and unsuccessful getting of article labels

🔧 Why We Need This

🚀 Proposed Solution

✅ Issue reporting checklist

  • I created a descriptive title for this issue
  • I checked that it hasn't been reported yet
  • I assigned the issue or added help-wanted label
  • I added appropriate labels

Fix broken link in README

✏️ Description

Link to contributing.md in README is currently broken

🔧 Why We Need This

Because README is our main page and we want it to be perfect ;)

🚀 Proposed Correction or Addition

Add correct link

✅ Documentation fix checklist

  • I created a descriptive title for this documentation fix
  • I checked that a similar documentation issue hasn't been reported yet
  • I assigned the issue or added help-wanted label
  • I assigned the documentation fix or added appropriate labels

[Project Config: env fix] optimize setup so that baseURL does not have to be defined in each test file

✏️ Description

The current project setup requires defining it and storing in a variable in each single test file. However, it's a good practice to have baseURL declared only in 1 place and use throughout the project. :)

🔧 Why We Need This

  • for maintenance reasons -> it will be easier to maintain the project if we have to adjust the baseURL in 1 place instead of changing it in every single test file; especially since we're planning to run the tests on CI which will make the whole setup a whole lot of easier
  • to make the project consistent with the DRY principle

✅ Issue reporting checklist

  • I created a descriptive title for this issue
  • I checked that it hasn't been reported yet
  • I assigned the issue or added help-wanted label
  • I added appropriate labels

Update Login/Patch/Get tests with correct version

✏️ Description

After PR #37 we have some problems to resolve. Some files were returned to their versions from 11 Nov

🚀 Expected Behavior

Updated version of files. Currently problems were observed for:
create-token.helper (fixed by PR #39 )
login test
patch test
get test
Other files changed by PR #37 should be analyzed

🛑 Current Behavior

login test and patch test are expecting old version of helper and cannot be run

🔁 Steps to Reproduce

Pull main branch and try to run tests mentioned above

📷 Screenshots or Additional Information

image

✅ Problem report checklist

  • I created a descriptive title for this problem report
  • I checked that a similar issue hasn't been reported yet
  • I assigned the problem report or added appropriate labels

[Test support] create a new user via faker lib

✏️ Description

Create a new user via faker.js library, and get logged in as this new user

🔧 Why We Need This

Faker.js is a great help when it comes to generating test data

✅ Issue reporting checklist

  • I created a descriptive title for this issue
  • I checked that it hasn't been reported yet
  • I assigned the issue or added help-wanted label
  • I added appropriate labels

Add tech.debt.log.md (placeholder)

✏️ Description

🔧 Why We Need This

🚀 Proposed Solution

✅ Issue reporting checklist

  • I created a descriptive title for this issue
  • I checked that it hasn't been reported yet
  • I assigned the issue or added help-wanted label
  • I added appropriate labels

PATCH /articles - add more tests

Continuation of: #24

Scope of changes:

  • add a comment to 200 OK test -> that explains the required criteria under which the test passes

  • add test: 401Unauthorized -> when invalid token is sent in headers

  • add test: 400 Bad Request -> when malformed json is used

  • add test: 422 Unprocessable Entity -> when keys are missing and values are too long

  • add types to all of the variables

Create initial basic project structure

Current Challenge

Currently, there's no project structure, just: Playwright, Typescript installed.

Proposed Solution

The initial proposed project structure is as follows:

directory description/responsibility
src/api all API related code - helpers, actions etc
src/e2e all UI related code - PageObjects (components, pages), helpers, actions etc
fixtures/api API related fixtures
fixtures/e2e UI related fixtures
tests/api all API tests
tests/e2e all UI tests

It can and most probably will be extended in the future

[CONFIG] Update imports to use absolute paths instead of relative paths

Challenge

Currently, we use relative paths in our project. That means we have to use .. to navigate to a given place, e.g.:
import { testUser } from "../../src/fixtures/api/auth";

Solution

We could switch to absolute paths in TypeScript! Instead of the above import, we would see:
import { testUser } from "@fixtures/api/auth";

Just a quick visual explanation of the difference between those two:
absolute path = C:\_Training\_discordQAgroup\_github_gad_repos\kawqa-gad-playwright\tests\api\login.spec.ts
relative path = tests\api\login.spec.ts

Why should we do it?

Well, with absolute paths we would:

  • achieve better readability of our code, and
  • managing imports (of libraries or helper functions, enums etc.) would be much easier to do

References:

Patch/articles - change of test 200 OK

✏️ Description

We use the constant value of article id = 1 in the test. This leads to failing the test in some cases.

🚀 Expected Behavior

We should not use the constant value of article id in the test.
The article must belong to the user who performs patch request on it.

🛑 Current Behavior

Using constant value of article id leads to failing the test in some cases.

🔁 Steps to Reproduce

📷 Screenshots or Additional Information

✅ Problem report checklist

  • I created a descriptive title for this problem report
  • I checked that a similar issue hasn't been reported yet
  • I assigned the problem report or added appropriate labels

[Tests support] add Given/When/Then to tests for better readability

✏️ Description

Add Given/When/Then to tests for better readability.

🔧 Why We Need This

Given/When/Then - same as Arrange/Act/Assert pattern gives a test much better readability.

✅ Issue reporting checklist

  • I created a descriptive title for this issue
  • I checked that it hasn't been reported yet
  • I assigned the issue or added help-wanted label
  • I added appropriate labels

[CI/CD] Investigate and fix conflicting dependency

✏️ Description

There's some sort of conflict with eslint libraries on CI:
https://github.com/kat-kan/kawqa-gad-playwright/actions/runs/7963281922/job/21738522791
Also, @Justyna-KO and @kat-kan experience the same issue on their side when running the linter locally.
On my side the issue is not reproducible.

🚀 Expected Behavior

There should be no issue with running pipeline on CI.

🛑 Current Behavior

There is an issue with running pipeline. During the dependencies installation step there is a following error printed:
npm ERR! Conflicting peer dependency: @typescript-eslint/[email protected]
npm ERR! node_modules/@typescript-eslint/parser
npm ERR!   peer @typescript-eslint/parser@"^7.0.0" from @typescript-eslint/[email protected]
npm ERR!   node_modules/@typescript-eslint/eslint-plugin
npm ERR!     dev @typescript-eslint/eslint-plugin@"^7.0.1" from the root project
npm ERR! 
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.

✅ Problem report checklist

  • I created a descriptive title for this problem report
  • I checked that a similar issue hasn't been reported yet
  • I assigned the problem report or added appropriate labels

[Project Config] add Prettier and ESLint to Husky pre-commit file

✏️ Description

To make better use of the Prettier and ESLint tools, both should be run pre-commit leveraging the Husky library

🔧 Why We Need This

Instead of remembering to run Prettier and the ESLint before each commit, we can automate this process. It saves time and is an enormous help in enforcing consistent coding practices :)

✅ Issue reporting checklist

  • I created a descriptive title for this issue
  • I checked that it hasn't been reported yet
  • I assigned the issue or added help-wanted label
  • I added appropriate labels

Github workflow standards && project standards to be established

Challenge

Currently, we don't have any rules established regarding GitHub workflow standards, and project standards.

GitHub workflow standards

  1. Contributor standards file, so called 'Contribution Guidelines' describing:
  • how to start working/contributing to the project
  • issue raising process
  • PR approval/code review process incl. PR merging & branch deletion
  1. Project settings - Issue's description && Pull Request's description
  • issue template with description guidelines -> #15
  • pull request template with description guidelines -> #16

Project standards

  1. file: README.md
    Project's README that includes:
  • repository/project main goals
  • list of project contributors
  • how-to work with repository: installation prerequisites; installation steps; how to run tests → #4
  • redirections to internal: CONTRIBUTION, DECISION_LOG files, and what the files contain - short description
  • redirections to 2 other repositories in which test cases are used, and how they will be used there - short description: https://github.com/kat-kan/kawqa-gad-docs, https://github.com/kat-kan/kawqa-gad-postman
  1. file: DECISION_LOG.md
    Decision log which will cover:
  • preparing decision log
  • short explanation why Playwright was selected for writing automation API checks
  • decision regarding project structure
  • coding standards, incl. tools for static code analysis #9
  • branches naming convention #8
  • commits naming convention

  1. file: CHANGELOG.md (do we need this? - currently no)
    Change log with the list of main commits that introduced important changes. Not sure if we need this or not.

  2. file: LICENSE.md (do we need this? - no)
    Info on the license we use. Not sure if we need this or not.

if there are any other items that we should cover, let's add them to the list :) and let's discuss those either here or on our Discord's channel after making some research, and providing a short summary of our findings on our notion page

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.