mirror of
https://github.com/verdaccio/verdaccio.git
synced 2024-12-16 21:56:25 -05:00
chore: increase unit testing documentation
This commit is contained in:
parent
aa94aa9b0c
commit
be7bbe9e60
1 changed files with 73 additions and 2 deletions
|
@ -36,7 +36,7 @@ Unit tests aim to test the CLI API and the Web API. The configuration file is lo
|
|||
|
||||
#### Testing an endpoint
|
||||
|
||||
We have prepared a template at `test/unit/api/api.__test.template.spec.js` that you can follow to create your own unit test. Only the tests are appended with `.spec.js` which will be found and used by `jest`.
|
||||
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.js` which will be found and used by `jest`.
|
||||
|
||||
> Feel free to suggest improvements to the template, there is still a lot of room for improvement.
|
||||
|
||||
|
@ -47,6 +47,77 @@ We recommend the following approach when you create a unit test:
|
|||
* Notice that all API spec files are appended with `api.[feature].spec.js`, we recommend to follow the same approach. eg: `api.[deprecate].spec.js`.
|
||||
* Don't mix utilities with API tests.
|
||||
|
||||
### How the mockServer works?
|
||||
|
||||
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.
|
||||
|
||||
Let's analyze the following example:
|
||||
|
||||
```js
|
||||
const configForTest = configDefault({
|
||||
auth: {
|
||||
htpasswd: {
|
||||
file: './test-storage-api-spec/.htpasswd'
|
||||
}
|
||||
},
|
||||
filters: {
|
||||
'../../modules/api/partials/plugin/filter': {
|
||||
pkg: 'npm_test',
|
||||
version: '2.0.0'
|
||||
}
|
||||
},
|
||||
storage: store,
|
||||
self_path: store,
|
||||
uplinks: {
|
||||
npmjs: {
|
||||
url: `http://${DOMAIN_SERVERS}:${mockServerPort}`
|
||||
}
|
||||
},
|
||||
logs: [
|
||||
{ type: 'stdout', format: 'pretty', level: 'trace' }
|
||||
]
|
||||
}, 'api.spec.yaml');
|
||||
|
||||
app = await endPointAPI(configForTest);
|
||||
mockRegistry = await mockServer(mockServerPort).init();
|
||||
```
|
||||
|
||||
The `configDefault({}, 'myConfig.yaml)` function is a method that returns a configuration file that will be the config used for your test.
|
||||
|
||||
* 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 generated object will be used for run your test, not for mock the mock server.**
|
||||
|
||||
The `app = await endPointAPI(configForTest);` will trigger the mock server that you are about to run your test with as an uplink. 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 file. **Any modification in the mock server might affect other test, since is a shared context**.
|
||||
|
||||
The `mockRegistry = await mockServer(mockServerPort).init();` mock registry will be used as `uplink`, this is optional, but the most of the test are using this for increase the number of tested scenarios.
|
||||
|
||||
> 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.
|
||||
>
|
||||
|
||||
### Runinng a single Test
|
||||
|
||||
To run a single test, use the following command:
|
||||
|
||||
```bash
|
||||
yarn jest test/unit/modules/api/api.spec.ts --coverage=false
|
||||
```
|
||||
|
||||
You might use the *jest* feature `.only` to limit the test suites you want to run, for instance.
|
||||
|
||||
```js
|
||||
describe.only('should test package api', () => {
|
||||
```
|
||||
|
||||
That will help to run small chunk of tests and makes more easy the development.
|
||||
|
||||
### Functional tests
|
||||
|
||||
The functional tests aim to run only **cli endpoint** and **web point** using real request to an existing and compiled running Verdaccio server.
|
||||
|
@ -118,7 +189,7 @@ Functional tests run over one single file, thus, it is not possible at this stag
|
|||
|
||||
### E2E Test
|
||||
|
||||
Verdaccio includes a Web User Interface that must be tested. We use End-to-End testing to run some smock tests against the web API using the UI Theme
|
||||
Verdaccio includes a Web User Interface that must be tested. We use End-to-End testing to run some mock tests against the web API using the UI Theme
|
||||
include by default.
|
||||
|
||||
```bash
|
||||
|
|
Loading…
Reference in a new issue