Skip to main content

Testing Flow And Architecture

This document shows the CI/CD (Continuous Integration/Continuous Development) flow of code from developer to repo.

Testing Systems Overview​

1. Developer Testing in Docker​

2. Automated Testing on Pull Request​

3. Review and QA Process​

End-to-End Testing Steps​

Testing Next.js fixes and features is a three step process involving developers, automation, and QA.

Developer Testing In Docker​

Developers can manually run tests within the Next.js Docker container.

Running unit tests using Jest within the Next.js Docker container is the first step to maintaining code consistency.

Any code changes should be checked to ensure that all tests pass:

% cd /home/nextjs-web
% pnpm test

The developer can also run conformance, type-checking, and link/Biome tests:

% cd /home/nextjs-web
% pnpm conformance
% pnpm type-check
% pnpm lint

The lint step uses Biome for both lint and formatting.

All of these tests should pass in order to increase the chances that your pull request will succeed.

Automated Testing on PR (pull request)​

When a developer submits a pull request, the same tests -- as listed in the previous step -- are automatically executed on your PR using Github Actions.

note

Failure of jest unit tests, conformance, type-check or lint/biome will cause the PR to fail.

In addition, two other sets of tests are automatically run:

note

Failure of Mabl or Veracode tests will not cause the PR to fail but may require developers to fix issues and resubmit their PR after QA review.

Trusted Committer Review​

After passing the automated tests, two trusted committers must sign-off on the pull request after a manual code review.

QA Testing after PR acceptance​

QA reviews any failing Mabl tests and either accepts the PR or sends it back for developer review.

Merging into main​

After acceptance by QA, the code is merged into the main branch.