Skip to content

Navigation Menu

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Commit 24fa8ea

Browse filesBrowse files
committed
Mocking global objects section
1 parent bb3021d commit 24fa8ea
Copy full SHA for 24fa8ea

File tree

1 file changed

+4
-4
lines changed
Filter options

1 file changed

+4
-4
lines changed

‎README.md

Copy file name to clipboardExpand all lines: README.md
+4-4
Original file line numberDiff line numberDiff line change
@@ -820,7 +820,7 @@ If you are using `--watch` mode, files included with the flag `--include` are no
820820

821821
#### Mocking global objects
822822

823-
Testing a functionality which requires global objects (`window.location` or `setTimeout`) is always a challenge. `window.location` is property which cannot be overridden but many tests require this property to be mocked. If you have a component which sets `window.location.href = 'some/new/url';`, then this code must be avoided in the tests, otherwise, it might break your current test execution (especially if you are running tests in the browser, e.g. with [karma-runner](https://www.npmjs.com/package/karma)). Dependency Injection can actually sort out this problem because we can inject the global object into your component and then we can pass custom object, without any restrictions, into a component in your tests.
823+
Testing a functionality which requires global objects (`window.location` or `setTimeout`) is always a challenge. `window.location` is a property that cannot be overridden but many tests require this property to be mocked. If you have a component which sets `window.location.href = 'some/new/url';`, then this code must be avoided in the test, otherwise, it might break your current test execution (especially if you are running tests in the browser, e.g. with [karma-runner](https://www.npmjs.com/package/karma)). Once again, the Dependency Injection can actually sort out this problem because we can inject the global object into your component and then we can pass custom object, without any restrictions, into a component in your test.
824824

825825
```js
826826
// di.js
@@ -832,15 +832,15 @@ import Vue from 'vue';
832832
import { LazyInject, WINDOW_ID } from './di';
833833

834834
export default class MyComponent extends Vue {
835-
@LazyInject(WINDOW_ID) window; // uses real window in PROD build, but can be mocked object in tests
835+
@LazyInject(WINDOW_ID) window; // uses real window in PROD build, but can be mocked otherwise
836836

837837
onClick() {
838838
this.window.location.href = 'some/new/url';
839839
}
840840
}
841841
```
842842

843-
... and your tests:
843+
... and your test:
844844

845845
```js
846846
// my-component.spec.js
@@ -859,7 +859,7 @@ afterEach(function () {
859859
});
860860

861861
it('should navigate to new url', function () {
862-
let myComponent = mount(MyComponent); // LazyInject in the component will inject windowMock instead of real window object
862+
const myComponent = mount(MyComponent); // LazyInject in the component will inject windowMock instead of real window object
863863
myComponent.onClick(); // this call now operates with windowMock, so no real navigation happens in the browser
864864

865865
expect(this.windowMock.location.href).to.equal('some/new/url'); // assert correct URL has been set

0 commit comments

Comments
0 (0)
Morty Proxy This is a proxified and sanitized view of the page, visit original site.