myfrontdesk-test

myfrontdesk-test

Setup

For the more detailed information about the framework please visit the Confluence space

Requirements

• Node (required for promise debug). Download link

Local environment

• Setup ssh, add it to your profile at Bitbucket and Jenkins. (If you have already set up the ssh then you can skip this step)

• Clone repository: git clone [e-mail]:cloudbeds/myfrontdesk-test.git

• Upgrade node

• Type npm i in the terminal to install the node_modules described in the package.json file.

• Create a devbox for testing based on your story. If the devbox already exists but is used by others it is wise to create another one. Remember to remove it after you finished testing.

• Create environment/local.env and set the next variables:

  • Devbox Write there a link to your devbox (created at the previous step).
  • Set debugRun=1 to see the test execution in the opened browser.
  • localPathToSSH Write the path to your private SSH file

Environment Configuration

Given the large number of moving parts in our E2E framework our enviroment variables and configurations are split between their area of concerns. When adding a new variable you should consider it's scope and where is the most relevant place for it to live.

• Fixtures - This stores configuration related to working with and accessing fixtures. It is NOT for storing the names of each various fixture. It will for instance hold configurations for SSH credentials, AWS credentials and directory structure etc.
• Fixture List -This configuration file is for holding details about each fixture available to us. It will hold the fixture names, user credentials specific to the fixtures. Each fixture should also outline it's use case and list any special set up or features enabled on it. This will allow future users to reuse and discover fixtures.
• Test - This is for storing configurations relevant to running tests. It will have values such as Locale for languages, or logging values. These values when used will affect how the tests are run.
• Users - Storing all users that aren't specific to a fixture that are reused between several scenarios. Users such as "Super Admin" would belong here, but a "HotelFixture3399_Owner" would not.
• Local - This is a file used for overwriting any previous configurations with your own local variables. You can set a "localPathToSSH" variable here which will be needed for running tests locally.

Working with configuration files

Run tests

• npm run test - to run all tests in the project
• npm run test -- e2e/tests/SmokeTests/newReservationCreation.test.ts - to run a single test (with a path to test as a parameter)
• npm run test:fast - to run all tests in the project and stop the running on the first fail

Using SDK to generate preconditions

Usage example:

import { scenario } from '@/core';
import { Property } from '@cloudbeds/cloudbeds-qa-sdk';
import { loginUsingSDKUserModel } from '@/middleware/loginUsingSDKUserModel';

describe(`TestTag`, () => {
  scenario('Test title', () => {
    it('Preconditions', async () => {
      const property = await Property.init();

      await loginUsingSDKUserModel(property);
    });

    it('1st test step', async () => {
      // test step code
    });
  });
});

Enabling features via Billing Portal API:

it('Preconditions', async () => {
  const property = await Property.init();
  const billing = await Billing.init(property.getModel());

  await (await billing.billingCustomerDataService.featuresBuilder(billing.getModel()))
    .paymentOptions(FeaturesFlags.FEATURE_ON)
    .updateFeatures();

  await loginUsingSDKUserModel(property);
});

NOTES:

• Enabling features via CRM API doesn't work properly. We need to init BillingPortalService and make changes to features here.

Using SDK service models:

Default user service models:

DefaultUserModels.PROPERTY_OWNER_MODEL
DefaultUserModels.SUPER_ADMIN_MODEL

Getting default service model while generating preconditions:

it('Preconditions', async () => {
  const property = await Property.init();

  console.log(property.user.getModel(DefaultUserModels.PROPERTY_OWNER_MODEL).email);
  console.log(property.user.getModel(DefaultUserModels.SUPER_ADMIN_MODEL).email);

  await loginUsingSDKUserModel(property);
});

Creating new House Account and getting it's model:

it('Preconditions', async () => {
  const property = await Property.init();
  const billing = await Billing.init(property.getModel());

  await (await billing.billingCustomerDataService.featuresBuilder(billing.getModel()))
    .houseAccounts(FeaturesFlags.FEATURE_ON)
    .updateFeatures();

  await property.houseAccount.create();
  console.log(property.houseAccount.getModel().name);

  await loginUsingSDKUserModel(property);
});

NOTES:

• console.log(property.houseAccount.getModel().name); will print created House Account name from model saved in property.houseAccount.create() method.
• default modelId naming pattern - model-{number}. Same House Account name also can be gotten by typing console.log(property.houseAccount.getModel('model-0').name);. Next created model id will be model-1 (2, 3, 4 etc.)

Creating new House Account with custom modelId:

it('Preconditions', async () => {
  const property = await Property.init();
  const billing = await Billing.init(property.getModel());

  await (await billing.billingCustomerDataService.featuresBuilder(billing.getModel()))
    .houseAccounts(FeaturesFlags.FEATURE_ON)
    .updateFeatures();

  await property.houseAccount.setModelId('privateHA').create({
    houseAccountName: 'Private HA',
    onlyForMe: true,
  });
  await property.houseAccount.setModelId('publicHA').create({
    houseAccountName: 'Public HA',
    onlyForMe: false,
  });
  console.log(property.houseAccount.getModel().name);
  console.log(property.houseAccount.getModel('privateHA').name);
  console.log(property.houseAccount.getModel('publicHA').name);

  await loginUsingSDKUserModel(property);
});

NOTES:

• console.log(property.houseAccount.getModel().name); - getting model without providing modelId, will print latest created House Account name - Public HA.
• console.log(property.houseAccount.getModel('privateHA').name); - getting model by specific ID, will print House Account name - Private HA.

Using SDK for describe.each() test pattern:

TODO

Tests migration process from fixtures to SDK

• Pick test file which should be migrated.
• Move it to /e2e/test/Sdk directory. Please keep directories structure of this file as it was in original /e2e/tests location.
• Create it('Preconditions', async () => { code part with all steps to generate preconditions according to example above.
• Commit and push changes. Merge PR to master branch.

Using dockerized version of e2e framework

Requirements:

• Required. Docker installed (https://docs.docker.com/get-docker/).
• Required. .ssh directory with id_rsa key inside in your home directory.
• Required. .aws directory with AWS credentials inside in your home directory.
• Required. Devbox created.
• Required. Create an User in quay.io
• Optional. Bash console with available docker command to use (instructions below are with using bash console).
• Optional. VNC viewer client (https://www.realvnc.com/ or any other).

Go to myfrontdesk-test local repository (cd command)

Step 1. Build docker image:

docker login quay.io
docker build -t myfrontdesk-test .

Step 2. Run docker container with VNC server inside

PROJECT_NAME=myfrontdesk-test && docker rm -f ${PROJECT_NAME} || true && docker run --name ${PROJECT_NAME} -p 8088:5900 -v "$(pwd)/e2e":/root/sources/e2e -v /mnt/c/Users/Yurii/.ssh:/root/.ssh -v /mnt/c/Users/Yurii/.aws:/root/.aws --env Devbox=mfd-devbox-e2e-test3-17023 --env updateDevboxWithDefault=0 --env debugRun=1 --env setupLogs=1 --env testLogs=1 --env stepTimeout=300000 -d myfrontdesk-test bash /root/sources/vnc-start.sh

NOTES:

• replace -v /mnt/c/Users/Yurii/.ssh with your local path to .ssh directory with id_rsa key inside.
• replace -v /mnt/c/Users/Yurii/.aws with your local path to .aws directory with AWS credentials inside.
• replace --env Devbox with your devbox url.
• change resolution of virtual display: bash /root/sources/vnc-start.sh -x 2560x1080. Default resolution is 1920x1080.
• WARNING! Do not mount node_modules dir inside docker container. It should be created and stored separately in docker image after docker build command execution (something related to user, permissions and OS where that directory has been created).

Step 3. Optional. Connect to VNC server using VNC client

Host: 127.0.0.1:8088

Password: password

Browser window will be opened inside docker container after executing next step. VNC client allows to see it.

Step 4. Run test inside docker container

docker exec -it myfrontdesk-test npm run test deleteDefaultPaymentMethod

NOTES:

• change npm run test deleteDefaultPaymentMethod command to your own one.

Step 5. Running test inside docker container without creating VNC server

docker run --rm -v "$(pwd)/e2e":/root/sources/e2e -v /mnt/c/Users/Yurii/.ssh:/root/.ssh --env Devbox=mfd-devbox-e2e-test3-17023 --env updateDevboxWithDefault=0 --env setupLogs=1 --env testLogs=1 --env stepTimeout=300000 -it myfrontdesk-test npm run test deleteDefaultPaymentMethod

NOTES:

• using this step does not require steps 2-4.
• browser will not be visible anywhere.
• change npm run test deleteDefaultPaymentMethod command to your own one.

Code Style Refactoring before Pull Request

• Use npm run lint to check your code and find all the possible style improvements can be made.
• Use npm run lint:fix to fix all the issues related to code standards.
• General best practices for e2e tests writing
• Bad practices and common mistakes in e2e tests writing

Allure report

• Setup Allure for reports. Installation instructions
• To see a report in browser, run in console allure serve
• If you want to generate html version, run in console allure generate

CI

• Jenkins Pipeline flow with Declarative

Test Process

1. Create feature/ branch in application repo (eg. accessa, billing_portal, etc.).
2. Create matching feature/ branch of the same name in myfrontdesk-test.
3. Create Test Preconditions
   1. Create preconditions via SDK in test code.
   2. If existing fixture - convert to SDK in test code.
      1. If unreasonable to convert at this time:
         1. Follow manual process to update fixture via devbox and jenkins.
         2. Add Comment of added/changed preconditions below fixture line in https://bitbucket.org/cloudbeds/myfrontdesk-test/src/master/fixtures/.env.fixtures.example
4. Run Tests - Squad Developer
   1. Run test suite being made/modified
   2. Run Smoke Suite
5. Create PR and link test runs - Squad Developer
   1. Ensure branch is up-to-date with master
   2. Ensure the "Close branch" checkbox is checked.
   3. Modifications of core files - Page Object, etc. requires full test run and QE approval
   4. If more commits to the branch since PR creation, tests in Step 4 re-run and update links
6. PR Review
   1. Have squad teammate review the test code and approach.
   2. QE member will review
      1. If QE is embedded on the team, assign them as reviewer, otherwise, leave unassigned and on-duty QE will review.
7. Merge Test repo PR immediately before App PR merged - Squad Developer
   1. This should be visible automatically in JIRA if naming is correct
8. If this was previously a TM4J manual test
   1. Set status to automated