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.
Commit 5bd73ce190 (#17367)
unintentionally truncated more of the traceback rather than less when
there’s more than one Module._compile frame.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
We have generally gone away from using $(...)
initialization in modules that we test with
zjsunit, but there are a few remaining special
cases related to our billing and portico
codebases.
This is prep toward allowing individual tests
to fail while continuing to run the test suite.
Most of the steps in namespace.finish() could
be put in a `finally` block, but once a test
fails, there's no reason to complain about
unused mocks, since there are bigger things
to address.
Factor out mock_cjs from mock_esm because adding __esModule prevents
mocks for CJS modules from being imported correctly.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Use fully resolvable request paths because we need to be able to refer
to third party modules, and to increase uniformity and explicitness.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
I now let folks override the same target multiple
times inside of `with_overrides` (and then indirectly
inside of `run_test`.)
I may re-impose this restriction in the future, since
most violations are due to code smells, but there are
a few legitimate use cases for this, and the code
can handle it, plus I want to remove some other
ugliness first.
We now just use a module._load hook to inject
stubs into our code.
For conversion purposes I temporarily maintain
the API of rewiremock, apart from the enable/disable
pieces, but I will make a better wrapper in an
upcoming commit.
We can detect when rewiremock is called after
zrequire now, and I fix all the violations in
this commit, mostly by using override.
We can also detect when a mock is needlessly
created, and I fix all the violations in this
commit.
The one minor nuisance that this commit introduces
is that you can only stub out modules in the Zulip
source tree, which is now static/js. This should
not really be a problem--there are usually better
techniques to deal with third party depenencies.
In the prior commit I show a typical workaround,
which is to create a one-line wrapper in your
test code. It's often the case that you can simply
use override(), as well.
In passing I kill off `reset_modules`, and I
eliminated the second argument to zrequire,
which dates back to pre-es6 days.
Steve Howell
Anders Kaseorg
Abhijeet Prasad Bodas
Riken Shah