1 | Testing a Ravel application is a relatively simple exercise with any popular testing framework, such as [jest](https://facebook.github.io/jest) (which Ravel uses for its own internal test suite).
|
2 |
|
3 | Much as with running the application, you will need a `.babelrc` file to transpile decorators:
|
4 |
|
5 | *.babelrc*
|
6 | ```js
|
7 | {
|
8 | "retainLines": true,
|
9 | "env": {
|
10 | "test": {
|
11 | "plugins": ["transform-decorators-legacy"]
|
12 | }
|
13 | }
|
14 | }
|
15 | ```
|
16 |
|
17 | Having done so, bootstrap your application the same way you run it:
|
18 |
|
19 | ```js
|
20 | describe('Some test', () => {
|
21 | let app;
|
22 | beforeEach(() => async () => {
|
23 | const Ravel = new require('ravel');
|
24 | app = new Ravel();
|
25 | app.set('keygrip keys', ['abc']); // required parameter
|
26 | app.set('log level', app.$log.NONE); // if you want to silence logging
|
27 | // load your app components
|
28 | app.scan('../src/modules', '../src/resources', '../src/routes');
|
29 | await app.init();
|
30 | });
|
31 | });
|
32 | ```
|
33 |
|
34 | ### Testing Modules
|
35 |
|
36 | Let's assume you have a `Module` with an injection name `'mymodule'` (either inferred from its filename or named manually via `@Module`). This `Module` can be accessed directly for testing after `app.init()` via `app.module('mymodule')`:
|
37 |
|
38 | ```js
|
39 | it('should do something', () => {
|
40 | const m = app.module('mymodule');
|
41 | expect(typeof m.method).toBe('function');
|
42 | expect(m.method()).toBe(true);
|
43 | });
|
44 | ```
|
45 |
|
46 | ### Testing Resources and Routes
|
47 |
|
48 | Much like testing `Module`s, `Resource`s and `Routes` can be accessed directly for unit testing via `app.resource(basePath)` and `app.routes(basePath)`, where `basePath` is the string passed to the `@Routes` or `@Resource` decorator.
|
49 |
|
50 | A more savvy approach to testing your endpoints, however, is to leverage [supertest](https://github.com/visionmedia/supertest) to make and validate real requests against your API:
|
51 |
|
52 | ```js
|
53 | const request = require('supertest');
|
54 | it('should respond in some way', async () => {
|
55 | // pass app.callback or app.server to supertest to give it access to your endpoints
|
56 | const res = await request(app.callback).get('/my/endpoint');
|
57 | expect(res.status).toBe(200);
|
58 | });
|
59 | ```
|
60 |
|
61 | ### Testing in Isolation
|
62 |
|
63 | If you wish to test an individual `Module`, `Resource` or `Routes` class without bootstrapping your entire application, you can leverage `app.load()` to load or mock components:
|
64 |
|
65 | ```js
|
66 | beforeEach(() => async () => {
|
67 | const Ravel = new require('ravel');
|
68 | app = new Ravel();
|
69 | app.set('keygrip keys', ['abc']); // required parameter
|
70 | app.set('log level', app.$log.NONE); // if you want to silence logging
|
71 | // You want to test IsolatedModule, which depends on AnotherModule
|
72 | const IsolatedModule = require('../src/path/to/module');
|
73 | // You can either require AnotherModule, or use a mock:
|
74 | @Ravel.Module('anothermodule')
|
75 | class AnotherModule {
|
76 | // mocked methods
|
77 | }
|
78 | // load your app components
|
79 | app.load(IsolatedModule, AnotherModule);
|
80 | await app.init();
|
81 | });
|
82 | ```
|