mirror of https://github.com/zulip/zulip.git
docs: Add mock_template documentation to docs.
Previously, this content was only available in an error message, and provided less context.
This commit is contained in:
parent
edb02fcc98
commit
a3feecac62
|
@ -153,6 +153,68 @@ The test runner (`index.js`) automatically runs all .js files in the
|
||||||
`web/tests` directory, so you can simply start editing a file
|
`web/tests` directory, so you can simply start editing a file
|
||||||
in that directory to create a new test.
|
in that directory to create a new test.
|
||||||
|
|
||||||
|
## Verifying HTML templates with `mock_template`
|
||||||
|
|
||||||
|
As a project, we prefer [end-to-end
|
||||||
|
testing][testing-philosophy-end-to-end] where possible, since those
|
||||||
|
tests are usually both more effective at catching bugs and cheaper to
|
||||||
|
maintain than tests that make heavy use of mocks.
|
||||||
|
|
||||||
|
One place where mocks can often be useful is when testing logic for
|
||||||
|
rendering an HTML template in Zulip. The interesting logic that one
|
||||||
|
wants to verify can be split between two places:
|
||||||
|
|
||||||
|
- Computing the **context data** object passed into the HTML template.
|
||||||
|
- Conditional logic in the HTML template itself.
|
||||||
|
|
||||||
|
It can work well to write tests that verify properties of the computed
|
||||||
|
HTML template, for example, is a given CSS class present in the
|
||||||
|
result.
|
||||||
|
|
||||||
|
But often, one can write a more readable test by instead verifying
|
||||||
|
the values of parameters in the context passed into the template
|
||||||
|
rendering. The `mock_template` function in Zulip's testing library
|
||||||
|
is designed to support this this.
|
||||||
|
|
||||||
|
We use `mock_template` in our unit tests to verify that the JS code is
|
||||||
|
calling the template with the expected context data. And then we use
|
||||||
|
the results of mock_template to supply the JS code with either the
|
||||||
|
actual HTML from the template or some kind of zjquery stub.
|
||||||
|
|
||||||
|
The `mock_template` function accepts 3 parameters:
|
||||||
|
|
||||||
|
- The path within `web/templates` to the [Handlebars
|
||||||
|
template](../subsystems/html-css.md) that you'd like to mock.
|
||||||
|
- Whether to call the actual template rendering function so that you
|
||||||
|
can verify the HTML generated by this specific template. Since
|
||||||
|
Handlebars rendering in tests takes time and rarely catches bugs, we
|
||||||
|
recommend using `false` if you're only planning to check the context
|
||||||
|
data.
|
||||||
|
- A callback function that you can use to include assertions about
|
||||||
|
what parameters were passed into the template. This function
|
||||||
|
receives a `data` parameter, with the context data, and an `html`
|
||||||
|
parameter if the real template was rendered.
|
||||||
|
|
||||||
|
The following illustrates the two common patterns for using this method.
|
||||||
|
|
||||||
|
```js
|
||||||
|
run_test("test something calling template", ({mock_template}) => {
|
||||||
|
mock_template("path/to/template.hbs", false, (data) => {
|
||||||
|
assert.deepEqual(data, {...};
|
||||||
|
// or assert.deepEqual(data.foo, {...});
|
||||||
|
return "stub-for-zjquery";
|
||||||
|
});
|
||||||
|
|
||||||
|
mock_template("path/to/template.hbs", true, (data, html) => {
|
||||||
|
assert.deepEqual(data, {...};
|
||||||
|
assert.ok(html.startWith(...));
|
||||||
|
return html;
|
||||||
|
});
|
||||||
|
});
|
||||||
|
```
|
||||||
|
|
||||||
|
[testing-philosophy-end-to-end]: https://zulip.readthedocs.io/en/stable/testing/philosophy.html#integration-testing-or-unit-testing
|
||||||
|
|
||||||
## Coverage reports
|
## Coverage reports
|
||||||
|
|
||||||
You can automatically generate coverage reports for the JavaScript unit
|
You can automatically generate coverage reports for the JavaScript unit
|
||||||
|
|
Loading…
Reference in New Issue