Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
-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
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