Testiramnpmbd NPM

BIC Unity PS Tests

Prerequisites

BIC unity tests utilize jsonnet to generate data for the tests. Please install go and jsonnet on your machine before running tests. There is also a dependency on bic-cypress-plugin.

Install node
- Make sure the node version is 16.x or higher
Install Chocolatey package manager for windows
- Installation instructions: https://chocolatey.org/install
Install go
- choco install golang
- Documentation: https://community.chocolatey.org/packages/golang
Install jsonnet
- go install github.com/google/go-jsonnet/cmd/jsonnet@latest
- Documentation: Go Jsonnet Github
Install @bd-infusion/bic-cypress-plugin
- Rename .npmrc-template to .npmrc
- Open the file npmrc and update the email with your BD email address
- In the same file, also update the tokens. The auth token is your GitHub access token
- While updating the token, do not remove // from the .npmrc as it is part of the syntax

!IMPORTANT
If you do not update the .npmrc properly then npm install will fail. This is because @bd-infusion/bic-cypress-plugin is not a public npm package.

Running tests

You can run the tests by utilizing the scripts in package.json. To run a test in a specific environment, call npm run on the script and pass the env variable.

npm run cypress:open:dev -- --env env=dev

Note: --env variables to the CLI might be required to put in double quotes for certain shells like powershell. Reference Cypress documentation on CLI env variables: https://docs.cypress.io/guides/guides/environment-variables#Option-4---env

Running tests in different environments

Following are the different commands to open Cypress in development mode:

npm run cypress:open:local -- --env env=local
npm run cypress:open:localhost -- --env env=localhost
npm run cypress:open:dev -- --env env=dev
npm run cypress:open:test -- --env env=test
npm run cypress:open:si -- --env env=si
npm run cypress:open:devops -- --env env=devops

Following are the commands to open Cypress in production mode:

npm run cypress:run:local -- --env env=local
npm run cypress:run:localhost -- --env env=localhost
npm run cypress:run:dev -- --env env=dev
npm run cypress:run:test -- --env env=test
npm run cypress:run:si -- --env env=si
npm run cypress:run:devops -- --env env=devops

Running tests with Git actions

Open your GitHub repository in a web browser.
Click the "Actions" tab at the top of the repository. This will take you to the GitHub Actions interface for your repository.
In the left sidebar, click on the workflow "run cypress test"
With the workflow selected, you'll see a "Run workflow" dropdown button on the right side of the workflow's page. Click on this button.
In the dropdown, you'll see fields for each of the workflow_dispatch inputs you defined in your workflow file. Fill these in with the values you want to use
- For the branch field, select branch that you want run test from.
- For the spec field, enter the path to the specific Cypress test file you want to run(example: cypress/e2e/ims/deviceGroup.cy.ts), or leave it as the default value to run all tests.
- Select the target environment.
Click the "Run workflow" button at the bottom of the dropdown. This will trigger the workflow with the inputs you provided.
The page will automatically navigate to the "Actions" tab where you can see your workflow run. Click on the workflow run to see more details.
Each job in your workflow will show up as a separate item in the workflow run's page. You can click on a job to see its logs.
If your workflow run produces any artifacts (like screenshots), these will show up in the "Artifacts" section of the workflow run's page.

Running tests with Cypress grep

Cypress grep is a plugin that is currently being used to run tests based on tags. More information about the plugin can be found here: https://github.com/cypress-io/cypress/tree/develop/npm/grep.

You can use a command like this to run tests with tags:

npm run cypress:run:dev -- --env env=dev,grepTags=test

One limitation of cypress grep is that it is slow to parse all the spec files. So, it is recommended to pass the --spec parameter to the run scripts. Please note that --spec parameter is not available with cypress open.

Following is an example of cypress running facility creation spec with tag filtering:

npm run cypress:run:dev -- --spec cypress/e2e/ims/facility* --env env=dev,grepTags=test

Running Sanity tests

Currently, we use Cypress grep plugin to filter out sanity test cases. This plugin is great but it is slow to filter out the tests. For now, use the following script to speed up test execution. An automated improvement to this will be introduced in the near future. The following script will run the tests against dev but please feel free to change the env variable in the script from dev to other envs. Please reference above sections on how to change the params.

npm run cypress:run:dev -- --spec cypress/**/psSanity.cy.ts,cypress/**/nbcTest.cy.ts,cypress/**/nbsSanity.cy.ts,cypress/**/deviceConnect.cy.ts,cypress/**/createBlankMasterList.cy.ts,cypress/**/createFluidMasterList.cy.ts,cypress/**/createTherapyMasterList.cy.ts,cypress/**/deployDrugLibrary.cy.ts,cypress/**/addTherapyToInfusion.cy.ts,cypress/**/approveDrugLibrary.cy.ts,cypress/**/copyCareTypeInDrug.cy.ts,cypress/**/createCareTypeDrugLibrary.cy.ts,cypress/**/createDrugLibrary.cy.ts --env env=dev,grepTags=sanity

Recording tests with Cypress cloud

Cypress run github action will sync test runs to Cypress cloud. The tests that run via GitHub action will have a tag of manualRun. Tests that are scheduled via GitHub action will have scheduledRun tag.

Development / Adding Tests

VS Code setup

The recommended IDE for bic-unity-ps-tests is VS Code. There is a settings.json inside .vscode folder that will configure the development environment along with the extension. Following are the recommended extensions that you must use:

ES Lint: ES lint is a plugin that uses the .eslintrc file to check for coding best practices and catch bugs during development.
Prettier: Prettier is a code formatter and is used to ensure uniform formatting of the code. Do not use any other plugin for formatting. Prettier is integrated with the VS Code IDE using the .vscode/settings.json file.
Code Spell Checker: This plugin is used to catch typos in code.
Cypress Helper: Cypress helper is a very powerful plugin that adds intellisense specifically for Cypress.

PR Best Practices

Some of the rules that you must follow while opening a new PR.

The PR must use the pull request template. All of the fields of the pull request template must be filled.
For revisions to a PR make sure that the replies to the pull request template are still valid.
PR must have less than 250 lines of code. If a PR is larger try breaking down your PR into multiple smaller ones.
PR must follow single responsibility principle. The PR should do only one thing.
PR commit messages should be clean and descriptive.

Refer to Anatomy of a perfect pull request for more information.

Git Best Practices

For this repo, we will follow certain conventions and role guidelines for development to make sure the git history looks clean. Following are the main tenets for the best git practices.

Do NOT cherry pick commits

Cherry picking commits might be a lucrative option to get away from solving merge conflicts in the short term but it can cause bigger merge conflicts down the road. Please refer to the following article which goes in depth about this issue: Stop cherry-picking, start merging.

If you do not want to read the full article please refer the following paragraph which explains the issue with cherry picking and the future merge conflicts that can arise:

"Basically, when you cherry-pick a commit, you now have two copies of the commit sitting in the graph. Any lines of code affected by that commit must remain untouched in both branches until the two copies of the commit finally merge. If either branch modifies any line touched by the cherry-pick, then that creates a powderkeg that can sit quietly indefinitely. It is at the time somebody tries to merge the two commits together that the explosion occurs, and that point could be in a faraway place not immediately related to the branches involved in the cherry-pick. This means that the person trying to resolve the merge was never part of the cherry-pick madness and may not know who to talk to in order to figure out what happened."

Use `git pull --rebase` to avoid merge commits

While developing on your feature branch it is important to keep your feature branch synced with the tracking branch.

Refer to the following article for more guidance on Git - When to Merge vs. When to Rebase. The core tenet for rebasing is merging is:

Rebases are how changes should pass from the top of hierarchy downwards and merges are how they flow back upwards.

Release Process

Do NOT create releases at this point with your PRs. Please ping a member of bic unity owners if you need your changes in the next release. The release process is currently changing. In future, every merged PR to main will trigger a new release.

bic-unity-ps-tests uses semantic-release for releasing PR merged into main branch. When PRs are merged to main branch, sematic update github action will run and create a release. For the release process to work, the commit message must follow some rules. Mainly, there are commit tags that need to be added to the commit message so that semantic release can figure out if major, minor or patch version needs to be released.

Semantic release tags are defined in .releaserc.json and they are case sensitive. The following example shows the types of commit messages that will trigger a release or not:

New: add new spec file for infusion therapy  # This will create a minor release
Add new spec file for infusion therapy       # This will NOT create a new release