First of all, we should explain the testing frameworks being used. We use `jest` and other tools such as **`supertest`** to be able to test the API, and **`puppeteer`** for End-to-End testing.
- We **type** all our tests. eg `const foo: number = 3;`
- **Each test should be as small as possible**: You should use the `test()` block to test only one thing and do not depend on other tests. If the test requires different steps, group them with a `describe()` block.
- All `test()`**headers titles** should begin with `test('should test ...')`: For consistency with reporting tools, this makes it easier to match the test with the feature needed to be tested.
- **Any mock data** should be located in the `partials` folder in each section.
- Use `yaml` for **configuration files examples** instead of JSON.
- If you use a **file based mock storage**, it should be located in the `store` folder in each section.
- All tests **MUST NOT** rely on external sources and must be able to run them **offline**.
- Tests **must run on the following Operating Systems**: Unix (Mac, Linux) and Windows (7 -> latest).
- If you are creating mock data file which use the state and need a clean state, use `rimraf` to remove folders.
Verdaccio testing is split in 3 sections, each of them has different setup and scope. The most important is the **unit test**. All sections have custom **jest configuration files**.
If you are adding new tests, comply with the following:
We have prepared a template at `test/unit/api/api.__test.template.spec.ts` that you can follow to create your own unit test. Only the tests are appended with `.spec.ts` which will be found and used by `jest`.
Each `[xxx].spec.ts` file usually triggers a `mockServer` on in the`beforeAll` phase. This is is handy since we might need a `uplink` server to test different scenarios.
- The _first argument_ allows you to override/extend the default configuration located `/test/unit/partials/config/yaml/default.yaml`.
- The *second argument*s is being used to override the base configuration file, you only need to set the name `api.spec.yaml` you are willing to use, the relative location will be `test/unit/partials/config/yaml/` and will be prefixed on runtime.
The `app = await endPointAPI(configForTest);` is the server that you are about to run your test against. The `app` object is used to call the endoints, for instance:
In the previous example, we are fetching `jquery` metadata from our server, we can define custom headers, expect some specific status and validate the body outcome.
The `mockRegistry = await mockServer(mockServerPort).init();` mock registry will be used as `uplink` for the `app` object described above, **this is optional**, but, the most of the tests are using this approach for increase the number of tested scenarios.
The _mock server_ has a static storage which is located `test/unit/partials/mock-store`, if you need add new packages, those must be commited in such folder. **Any modification in the mock server might affect other test, since is a shared context**.
> It is not possible yet to override the mocks configuration server.
> The `self_path` is a legacy prop that must to be set manually, this prop is being generated by the CLI, but running the test without the CLI force use to generate it manually. **This might change in the future**.
> The `const mockServerPort = 55549;` mock server must be added manually, be careful and try to define a port that is not being used by another test, there is not automation here yet.
> To increase debugging you might override the `logs` property using `{ type: 'stdout', format: 'pretty', level: 'trace' }` level **trace**, thus the test will display the server request in your terminal, try to keep it in **warn** by default to avoid noise on run all your test.
In order to inspect more information about what is being sended between your test and the mock server, you might take advance of the `debug` library used by `request`, for instance.
> Be aware if you change something in the `{root}/src` source code, you must run `yarn code:build` before to be able to see your changes because functional tests use the transpiled code.
All tests must be included in the `test/functional/index.spec.ts` file, which bootstraps the whole process. There is only one spec file and **must be only one**.
The jest configuration file is defined in `test/jest.config.functional.js`. The configuration will create a custom environment launching 3 Verdaccio servers with different configurations.
You can find more in our [guide about run and debugging test](https://github.com/verdaccio/verdaccio/wiki/Running-and-Debugging-tests#running-the-test).
## Continuous Integration
Verdaccio uses [CircleCI](https://circleci.com/gh/verdaccio) as its primary Continuous Integration tool. We run the tests against the most common Node.js versions available. Among them is LTS and the latest release. Before the PR is being merged, all checks must be green.
