This is consistent with Jest and other standard test runners, and is
necessary to support asynchronous tests.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This increases consistency and saves a bit of code, but more
importantly, it makes it much easier to switch between these APIs
while refactoring tests.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This reverts part of commit d4c681a937
(#20764).
The ternary conditions are necessary because __Rewire__ can be (and in
fact is) used to patch non-exported variables.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
When you use nyc, its code instrumentation transforms
the code so that line numbers and columns no longer
make sense, and the long stack trace is likely to cause
more confusion than convenience.
We want to encourage a workflow where you debug your
node tests using the normal (and much quicker mode)
before running `--coverage`.
Translation handlebars helpers were not getting changed when we
mock static/js/i18n.ts and then unmock it in a different test.
We mock i18n.ts for every test except node_tests/i18n.js.
So, running any code that calls the registered handlebar
helpers related to translations before running i18n test
will run the helper functions registered with mocked i18n module.
The subsequent tests too would use those functions registered
with mocked i18n module.
This causes the i18n test to fail as we expect the registered
helpers to use actual i18n.ts instead of a mock if we have
code that would call the registered translation helpers in
tests that run before i18n.
This commit adds code for live-updating the realm-level default
settings page which contains only display settings as of now.
This commit also adds realm_user_settings_defaults object to
zpage_params so that we can write the tests.
I also remove a conditional here that's not necessary. For
anything that's obviously a template in static/templates,
we now create a stub implementation that behaves according
to whether we're stubbed or being included as a partial.
We now only expose mock_template as a helper in run_test.
This has the following advantages:
* less boilerplate at the top of the file
* more surgical control with setting exercise_templates
* no more "f" hack (or render_foo consts)
* we force devs to explicitly mock the template
See frontend_tests/zjsunit for the substantive changes.
All the changes to the tests are very mechanical in nature.
There is still no need for mock_template to reach into the internals
of mock_cjs. Make it a normal caller of mock_cjs.
This is basically the same as 60f5a00c09
(#18804), because the same abstraction violation was since
reintroduced in the same way.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
If you call mock_template(fn, true), we will
call the actual template code and pass it to your
stub for verification.
We make this opt-in to prevent false positives
on template line coverage.
We special-case our handling of static/js/templates.js,
since it's important that all of our tests have
the Zulip-specific handlers for Handlebars pre-registered.
This runs in roughly the same amount of time as the
previous commit.
This is necessary for the new `mock_template` helper added in
97ad6b6b62 to work correctly without
leaks, since it uses `mock_cjs` under the hood.
This logic was added in 216493aae8.
There is no need for mock_template to reach into the internals of
mock_cjs. Make it a normal caller of mock_cjs.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
We use css() pretty rarely in our codebase, and
it can sometimes be used mistakenly, when a better
alternative is to toggle a class for external css.
It's hard to support the full API in zjquery, so
we just punt and tell folks to create their own
stubs.
Most of the existing tests that were "fixed" here
weren't actually verifying the behavior of the css()
calls, and for those I just create no-op stubs.
In a few places I verify that css() was called as
expected.
Anders Kaseorg
Steve Howell
YashRE42
Dinesh
Sahil Batra
Tim Abbott
Abhijeet Prasad Bodas
Riken Shah