Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Complete SDET assignment #7

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

iakovenm
Copy link

@iakovenm iakovenm commented Sep 11, 2024

This PR is for completion of SDET Assignment:

Solution is using Playwright automation framework + Javascript.
It is POM based. Main emphasis was done on structure and dynamic/reusability of framework then on test coverage.
Because the way how structure is done defines how successful you may increase your coverage in future.

Steps done to set up the env:

  1. Fork repository
  2. Make sure you have Node.js installed
  3. Set up playwright.config indicating all needed info. Important things to pay attention to:
    -environment usage - locally read env variables from .env file,
    -tests are running in headless mode in CI and in headed locally
    -amout of workers are defined on CI and not defined locally
    -reportes are html and junit
  4. Install needed dependencies by running commands:
  • Playwright: "npm init playwright@latest"
  • faker library to generate data for Signup test: "npm i @faker-js/faker"

Test repository overview:

This solution has .env file where our test user data, and env urls are stored.
Locally my solution is reading variables from those file. On CI sensative values are preferrably stored in Github secrets
(but my in solution Github Actions reads directly from my .env file, I had some issues to make it read directly from secrets.)
To select environment run command: $ENV:TEST_ENV="test"
To run tests run command:"npx playwright test"

Page objects:

Solution has actual page objects with ending "-page.js" which represent actual pages on UI as well as component page object called form.js
Component represent functional part of application that could be used in multiple places of application and ideally it should be just a simple class not a page object.
In our case some locators in form.js component use native playwright's getByRole/getByLabel tied to Playwright's Page object.
That is why form.js is implemented as page object but in practice it could be used as a component on different pages.

All Page objects have locators created as getters to be able to use chaining.
All methods have JSDocs.

-form.js
Represent form to populate sign up/login data.
It has populateForm method which populates data for provided fields and setter methods to set fields depending on their type - text or select

-home-page.js
Represents page with locators for elements on main home page crexi.com and on main page after user login
Sets the page to the correct playwright object type to enable code completion.
Is being inherited by other pages to set pages default constructors and correct playwright object type

-account-settings-page.js
Represents Account Settings and related locators and methods.
Ideally we could create separate page objects for each actual page/component representation in the application if we have wider test coverage.
In our case as test coverage is pretty small I didn't go more granular

properties-page.js
Represents Properties Page with locators and functions related to it

sign-up-login.page
Represents SignUp/Login panel with locators and functions related to it.

Test specs:

-signup-and-login.spec.js
1)For successful sign up scenario user has to have valid email.
Automating this scenario would require valid email and clean up mechanism at the end of the test.
If I had access to DB I would build connection string to DB and perform SQL query to check that after user signed up user data is populated in DB and then delete it.
However I decided to implemented functionality for filling in sign up form with it's submition just to show how would first part of the test look like.
I created seperate file with functions to generate data for sign up using faker library which provides random data.
This approach was used to showcase how we can incorpotate data generation mechanism into our framework.
Using helper data libraries such as faker depend on projects requirements, safety policies, data strategy etc.

2)For login scenario I used my actual email and password.
Using sensative data would require to store it in some safe place (like secret manager) or use some masking data mechanism such as encrypt/decrypt

-update-profile-photo.spec.js
Test is using testUserLoginAccountProfilePage login fixture to go directly to user Account Settings page.
In my test I am uploading profile picture only and checking for particular locators/requests to be completed to verify photo was uploaded successfully, and changed successfully
If I had more time, good candidates for extra test coverage would be uploading cover photo,check for different size and format of picture to be uploaded

-property-details-and-search.spec.js
1)Test spec includes test for checking if Properities section is displayed when particular property is being clicked on

2)For property search I just added a test for selecting a search filter and checking if selecting filter will trigger the records update.
Not sure if for this test actual search box was ment to be used but I decided to use a filter (let me know and if needed I will create test for that as well)

Loading Test Results:

I generated public API key from Uploadcare, added them to secrets (UPLOADCARE_PUBLIC_KEY) in my GitHub repository .
In my GitHub Actions workflow I added a section for running curl command with posting the results
Latest result is in here
report.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant