1.0.0 • Published 7 months ago

qa_automation_api v1.0.0

Weekly downloads
-
License
ISC
Repository
-
Last release
7 months ago

Usage

Test Suites

Windows

run_tests.bat

Mac/Linux

./run_tests.sh

Individual App 

node run_tests <app_name> <environment_file> <user_type>:<email>

node run_tests HBSAlumniGivingService secure_stage_hbsstg student:jslovin@mba1996stg.hbsstg.org

Individual Script

This will traverse subdirectories looking for the specified script. To configure environment, edit package.json "testWin" or "testMac" script.

npm run (testWin or testMac) <script_name>

npm run testWin hacs_getSubmissions_external.spec.js

Setup

Node.js

Node.js is a prerequisite to using this framework. We recommend the latest LTS version (18.12.1 as of this writing) There are several ways to install node.

Official Installer

https://nodejs.org/en/

Alternatives

https://www.nodejsdesignpatterns.com/blog/5-ways-to-install-node-js/

Clone Git Repo

git clone https://code.harvard.edu/HBS/qa_automation_api.git

Install and Update modules

These commands install the node modules specified in the package.json file. From the project's root directory, run the following:

npm install
npm update

Authentication

Authentication information is stored in ./credentials.json and ./secrets.json. Placeholder versions are included in github.

After initial configuration (below), authentication is handled by the framework. Users added in tests and in package.json will use provided credentials or CEE pwds from secrets.json.

Configure initial credentials and secrets

The framework doesn't update passwords, so they must be initially set manually. We don't store secrets in git, so you need to add/create them in these files

Update utils/credentials.json (already has a skeleton in place, just add user's info) 1. Open the file and update the passwords for each type of users. 2. Save.

Create utils/secrets.json 1. Create a file named secrets.json in the utils folder. 2. Follow this simple JSON format:

{
  "staff": "super secret password",
  "mba": "super secret password",
  "exed": "super secret password",
  "alumni": "super secret password",
  "public": "super secret password",
  "crossreg": "super secret password"
}

How to configure/use authentication

During execution the framework uses credentials.json to set a CAS cookie for the specified users. The test cases then pull the cookie for a specifis user when configuring the request object.

Users are specified 2 ways:

  • Per app - specified in package.json scripts ; This method updates credentials.json

    Configure ./package.json "scripts":
<script name>: "node <script runner> <app name> <env file> <optional username>",

"testAccountHealthCheck": "node run_tests AccountHealthCheck secure_stage_hbsstg cweinberg@hbsstg.org",

Reference cookie in test:
auth = require('../../../utils/credentials.json')

    it('TC-001 - hacs_changeCaption_external - This API call returns correct response with 200 status code', (done) => {
    
       request.post(data.TC001.endpoint)
              .set("Content-Type", "text/html")
              .set("Cookie",auth.cas_stu.cookie)
              .set("accept", "text/html")
              .end((err, res) => {
                if (err) done.fail(err);
                expect(res.status).toBe(200);
                done()
              });
    });

  • Per test - specified in test data json file: On the fly and not persisted

Gets MOD_AUTH_CAS cookie for specified user (in this case Exed alum)
data.TC001.username = "alumnX@apm163stg.hbsstg.org"

authCookie = await login.getModAuthCASCookie(data.TC001.username, 'alu');
      await request.get(data.TC001.endpoint)
                   .set("Content-Type", "application/json")
                   .set("Cookie", authCookie)

For 'per app'... CAS.js and changeUser.js files are utilized (by the framework) to update credentials.json with the new user and cookie. The new user remains the active user (of that type e.g. Staff, Student, etc...) UNTIL:

  • changed in next app (package.json)
  • credentials.json is edited

Utilizing 'per test' method doesn't update credentials.json (so, you can use it for one test and then call credentials.json in the next)

Project Structure

Top Level

├── allure-report
├── allure-results
├── allure_features
├── config
├── history
├── logs
├── node_modules
├── projects
├── responses
└── utils

Reporting

Allure Report is our reporting tool. Allure reports are not static. To view them, you must run the allure server. Reports are created on a per app basis. Allure Commandline must be installed on the host. Allure Commandline Docs To view a report:

cd <app directory> e.g. /Users/cweinberg/git/qa_automation_api/history/2022-12-05_13-26/AccountHealthCheck
allure open

Usage and Information about some Important folders

./allure_feature : This Folder contain files which provides additional section information in allure report for ex Information about executor, environment properties etc. ./allure-report : This Folder contain data files which are used to create allure report by allure reporting tool files for ex history ,trends etc. ./allure-results : This Folder have xml files which contains test execution's result data for every single testcase ./config : This folder contain json files which have base URLs for multiple sevices inside it ./node_modules : This folder contain all the libraries which are installed and used within HBS automation framework ./projects : This folder contains multiple automated projects which are used in HBS automation framework ./utils : In this folder we have all files that contains global data and that data further used within automation scripts.

CEE Project Info

  1. AccountHealthCheck

  2. AccountManagementWS

  3. AlumniElasticSearch

  4. CalendarEventWebServices

  5. CanvasCourseArchive

  6. CheckList

  7. Classcards

  8. Cmat

  9. ConfigurationManagementService

  10. CPDAlumniProvisioningService

  11. EnterpriseWrapperService

  12. HBSExEdAccountBuilder

  13. ExamV3

  14. GroupWS

  15. HBSAlumniGivingService

  16. HBSAlumniMessagingServices

  17. HBSAlumniClassNotesService

  18. HBSCallTool

  19. HBSCPDEventsService

  20. HBSEstimatorService

  21. HBSGeoServices

  1. HBSMessagingService

  1. HBSPlanningEventsService

  2. HBSSecuredAccounts

  3. HBSSimAuth

  4. IndependentProjects

  5. NameRecording

  6. PanoptoWrapperService

  7. PeerFeedbackTool

  8. Poll

  9. PubReg

  10. TMT

allureallure-commandlinebasic-ftpbcryptconcat-streamcryptoexpressfetch-cookiefollow-redirectsform-datafsjest-allurejest-allure-reporterjoi-machinejsonmomentnode-fetchnodemailerrimrafserve-indexsocket.iounirestwinstonxml2jsyargs
@everything-registry/sub-chunk-2500
1.0.0

7 months ago