Testing: inconsistencies between Location and SpyLocation #27059

robisim74 · 2018-11-12T14:08:52Z

🐞 bug report

Affected Package

The issue is caused by package @angular/common/testing

Is this a regression?

No, I think it never worked.

Description

The normalize method in the Location class works correctly, when in the SpyLocation class it always returns null (https://github.com/angular/angular/blob/7.0.3/packages/common/testing/src/location_mock.ts#L120)
The subscribe method in the Location class is fired only on popstate event (https://github.com/angular/angular/blob/7.0.3/packages/common/src/location/location.ts#L140), when in the SpyLocation class is fired on each navigation (https://github.com/angular/angular/blob/7.0.3/packages/common/testing/src/location_mock.ts#L115)

🔥 Exception or Error

The different behavior breaks the tests.

🌍 Your Environment

Angular Version:

Angular CLI: 7.0.1
Node: 8.11.1
OS: win32 x64
Angular: 7.0.0

Anything else relevant?
There are unresolved issues related to these inconsistencies: #10963 and https://stackoverflow.com/questions/47484775/location-class-from-angular-common-doesnt-work-in-unit-tests

Thanks!

The text was updated successfully, but these errors were encountered:

yggg · 2019-06-29T19:40:42Z

Also, SpyLocation.path method always returns path with the fragment when Location has an includeHash parameter which is false by default.

ondrasej · 2020-07-25T20:09:36Z

Also, SpyLocation.path()returns only the path, but not the query. Location.path() returns the path and the query.

do not emit event for imperative navigation. emit a `popstate` event before each `hashchange` to have the same behavior of the `history API`. BREAKING CHANGE: After this change we should not use location.go to test an imperative navigation, we have to use route.navigate or route.navigateByUrl methods. `popstate` will be emitted before each `hashchange` event. We'll need to remove all `simulateUrlPop` called before `simulateHashChange` in the spec files. fixes angular#27059

* Do not emit url pop on Location.go * Emit a `popstate` event before each `hashchange` to have the same behavior of the browser. * Track the url change in the internal history when calling `simulateHashChange` BREAKING CHANGE: The behavior of the `SpyLocation` used by the `RouterTestingModule` has changed to match the behavior of browsers. It no longer emits a 'popstate' event when `Location.go` is called. In addition, `simulateHashChange` now triggers _both_ a `hashchange` and a `popstate` event. Tests which use `location.go` and expect the changes to be picked up by the `Router` should likely change to `simulateHashChange` instead. Each test is different in what it attempts to assert so there is no single change that works for all tests. Each test using the `SpyLocation` to simulate browser URL changes should be evaluated on a case-by-case basis. fixes angular#27059

* Do not emit url pop on Location.go * Emit a `popstate` event before each `hashchange` to have the same behavior of the browser. * Track the url change in the internal history when calling `simulateHashChange` The changes to the router tests reflect the goals of the test. Generally when `Location.go` is used to trigger navigations, it is only relevant for `HashLocationStrategy` and verifying that the Router picks up changes from manual URL changes. To do this, we convert those calls to `simulateHashChange` instead. Manual URL bar changes to the path when not using the `HashLocationStrategy` would otherwise trigger a full page refresh so they aren't relevant to these test scenarios which assert correct behavior during the lifetime of the router. BREAKING CHANGE: The behavior of the `SpyLocation` used by the `RouterTestingModule` has changed to match the behavior of browsers. It no longer emits a 'popstate' event when `Location.go` is called. In addition, `simulateHashChange` now triggers _both_ a `hashchange` and a `popstate` event. Tests which use `location.go` and expect the changes to be picked up by the `Router` should likely change to `simulateHashChange` instead. Each test is different in what it attempts to assert so there is no single change that works for all tests. Each test using the `SpyLocation` to simulate browser URL changes should be evaluated on a case-by-case basis. fixes angular#27059

* Do not emit url pop on Location.go * Emit a `popstate` event before each `hashchange` to have the same behavior of the browser. * Track the url change in the internal history when calling `simulateHashChange` The changes to the router tests reflect the goals of the test. Generally when `Location.go` is used to trigger navigations, it is only relevant for `HashLocationStrategy` and verifying that the Router picks up changes from manual URL changes. To do this, we convert those calls to `simulateHashChange` instead. Manual URL bar changes to the path when not using the `HashLocationStrategy` would otherwise trigger a full page refresh so they aren't relevant to these test scenarios which assert correct behavior during the lifetime of the router. [Reference](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event) > Note that just calling history.pushState() or history.replaceState() won't trigger a popstate event. The popstate event will be triggered by doing a browser action such as a click on the back or forward button (or calling history.back() or history.forward() in JavaScript). BREAKING CHANGE: The behavior of the `SpyLocation` used by the `RouterTestingModule` has changed to match the behavior of browsers. It no longer emits a 'popstate' event when `Location.go` is called. In addition, `simulateHashChange` now triggers _both_ a `hashchange` and a `popstate` event. Tests which use `location.go` and expect the changes to be picked up by the `Router` should likely change to `simulateHashChange` instead. Each test is different in what it attempts to assert so there is no single change that works for all tests. Each test using the `SpyLocation` to simulate browser URL changes should be evaluated on a case-by-case basis. fixes angular#27059

* Do not emit url pop on Location.go * Emit a `popstate` event before each `hashchange` to have the same behavior of the browser. * Track the url change in the internal history when calling `simulateHashChange` The changes to the router tests reflect the goals of the test. Generally when `Location.go` is used to trigger navigations, it is only relevant for `HashLocationStrategy` and verifying that the Router picks up changes from manual URL changes. To do this, we convert those calls to `simulateHashChange` instead. Manual URL bar changes to the path when not using the `HashLocationStrategy` would otherwise trigger a full page refresh so they aren't relevant to these test scenarios which assert correct behavior during the lifetime of the router. [Reference for no `popstate` on `pushState`/`replaceState`](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event) > Note that just calling history.pushState() or history.replaceState() won't trigger a popstate event. The popstate event will be triggered by doing a browser action such as a click on the back or forward button (or calling history.back() or history.forward() in JavaScript). [Reference for `popstate` before `hashChange`](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event#when_popstate_is_sent) > When the transition occurs, either due to the user triggering the browser's > "Back" button or otherwise, the popstate event is near the end of the process to transition to the new location ... > 12. If the value of state changed, the popstate event is sent to the document. > 13. Any persisted user state is restored, if the browser chooses to do so. > 14. If the original and new entry's shared the same document, but had different fragments in their URLs, send the hashchange event to the window. BREAKING CHANGE: The behavior of the `SpyLocation` used by the `RouterTestingModule` has changed to match the behavior of browsers. It no longer emits a 'popstate' event when `Location.go` is called. In addition, `simulateHashChange` now triggers _both_ a `hashchange` and a `popstate` event. Tests which use `location.go` and expect the changes to be picked up by the `Router` should likely change to `simulateHashChange` instead. Each test is different in what it attempts to assert so there is no single change that works for all tests. Each test using the `SpyLocation` to simulate browser URL changes should be evaluated on a case-by-case basis. fixes angular#27059

…ations The management of `browserUrlTree` currently has several problems with correctly tracking the actual state of the browser. This change makes the Router eagerly update the `browserUrlTree` when handling navigations triggered by browser events (i.e., not 'imperative'). This is becauses with those types of navigations, the browser URL bar is _already_ updated. If we do not update the internal tracking of the `browserUrlTree`, we will be out of sync with the real URL if the navigation is rejected. It would be best if we could remove `browserUrlTree` completely, but doing that would require a lot more investigation and is blocked by angular#27059 because the SpyLocation used in tests does not emulate real browser behavior. fixes angular#43101

…ations The management of `browserUrlTree` currently has several problems with correctly tracking the actual state of the browser. This change makes the Router eagerly update the `browserUrlTree` when handling navigations triggered by browser events (i.e., not 'imperative'). This is because with those types of navigations, the browser URL bar is _already_ updated. If we do not update the internal tracking of the `browserUrlTree`, we will be out of sync with the real URL if the navigation is rejected. It would be best if we could remove `browserUrlTree` completely, but doing that would require a lot more investigation and is blocked by angular#27059 because the SpyLocation used in tests does not emulate real browser behavior. fixes angular#43101

…ations (#43102) The management of `browserUrlTree` currently has several problems with correctly tracking the actual state of the browser. This change makes the Router eagerly update the `browserUrlTree` when handling navigations triggered by browser events (i.e., not 'imperative'). This is because with those types of navigations, the browser URL bar is _already_ updated. If we do not update the internal tracking of the `browserUrlTree`, we will be out of sync with the real URL if the navigation is rejected. It would be best if we could remove `browserUrlTree` completely, but doing that would require a lot more investigation and is blocked by #27059 because the SpyLocation used in tests does not emulate real browser behavior. fixes #43101 PR Close #43102

* Do not emit url pop on Location.go * Emit a `popstate` event before each `hashchange` to have the same behavior of the browser. * Track the url change in the internal history when calling `simulateHashChange` The changes to the router tests reflect the goals of the test. Generally when `Location.go` is used to trigger navigations, it is only relevant for `HashLocationStrategy` and verifying that the Router picks up changes from manual URL changes. To do this, we convert those calls to `simulateHashChange` instead. Manual URL bar changes to the path when not using the `HashLocationStrategy` would otherwise trigger a full page refresh so they aren't relevant to these test scenarios which assert correct behavior during the lifetime of the router. [Reference for no `popstate` on `pushState`/`replaceState`](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event) > Note that just calling history.pushState() or history.replaceState() won't trigger a popstate event. The popstate event will be triggered by doing a browser action such as a click on the back or forward button (or calling history.back() or history.forward() in JavaScript). [Reference for `popstate` before `hashChange`](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event#when_popstate_is_sent) > When the transition occurs, either due to the user triggering the browser's > "Back" button or otherwise, the popstate event is near the end of the process to transition to the new location ... > 12. If the value of state changed, the popstate event is sent to the document. > 13. Any persisted user state is restored, if the browser chooses to do so. > 14. If the original and new entry's shared the same document, but had different fragments in their URLs, send the hashchange event to the window. BREAKING CHANGE: The behavior of the `SpyLocation` used by the `RouterTestingModule` has changed to match the behavior of browsers. It no longer emits a 'popstate' event when `Location.go` is called. In addition, `simulateHashChange` now triggers _both_ a `hashchange` and a `popstate` event. Tests which use `location.go` and expect the changes to be picked up by the `Router` should likely change to `simulateHashChange` instead. Each test is different in what it attempts to assert so there is no single change that works for all tests. Each test using the `SpyLocation` to simulate browser URL changes should be evaluated on a case-by-case basis. fixes angular#27059

…ations (angular#43102) The management of `browserUrlTree` currently has several problems with correctly tracking the actual state of the browser. This change makes the Router eagerly update the `browserUrlTree` when handling navigations triggered by browser events (i.e., not 'imperative'). This is because with those types of navigations, the browser URL bar is _already_ updated. If we do not update the internal tracking of the `browserUrlTree`, we will be out of sync with the real URL if the navigation is rejected. It would be best if we could remove `browserUrlTree` completely, but doing that would require a lot more investigation and is blocked by angular#27059 because the SpyLocation used in tests does not emulate real browser behavior. fixes angular#43101 PR Close angular#43102

…ngular#41730) * Do not emit url pop on Location.go * Emit a `popstate` event before each `hashchange` to have the same behavior of the browser. * Track the url change in the internal history when calling `simulateHashChange` The changes to the router tests reflect the goals of the test. Generally when `Location.go` is used to trigger navigations, it is only relevant for `HashLocationStrategy` and verifying that the Router picks up changes from manual URL changes. To do this, we convert those calls to `simulateHashChange` instead. Manual URL bar changes to the path when not using the `HashLocationStrategy` would otherwise trigger a full page refresh so they aren't relevant to these test scenarios which assert correct behavior during the lifetime of the router. [Reference for no `popstate` on `pushState`/`replaceState`](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event) > Note that just calling history.pushState() or history.replaceState() won't trigger a popstate event. The popstate event will be triggered by doing a browser action such as a click on the back or forward button (or calling history.back() or history.forward() in JavaScript). [Reference for `popstate` before `hashChange`](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event#when_popstate_is_sent) > When the transition occurs, either due to the user triggering the browser's > "Back" button or otherwise, the popstate event is near the end of the process to transition to the new location ... > 12. If the value of state changed, the popstate event is sent to the document. > 13. Any persisted user state is restored, if the browser chooses to do so. > 14. If the original and new entry's shared the same document, but had different fragments in their URLs, send the hashchange event to the window. BREAKING CHANGE: The behavior of the `SpyLocation` used by the `RouterTestingModule` has changed to match the behavior of browsers. It no longer emits a 'popstate' event when `Location.go` is called. In addition, `simulateHashChange` now triggers _both_ a `hashchange` and a `popstate` event. Tests which use `location.go` and expect the changes to be picked up by the `Router` should likely change to `simulateHashChange` instead. Each test is different in what it attempts to assert so there is no single change that works for all tests. Each test using the `SpyLocation` to simulate browser URL changes should be evaluated on a case-by-case basis. fixes angular#27059 PR Close angular#41730

…ations (angular#43102) The management of `browserUrlTree` currently has several problems with correctly tracking the actual state of the browser. This change makes the Router eagerly update the `browserUrlTree` when handling navigations triggered by browser events (i.e., not 'imperative'). This is because with those types of navigations, the browser URL bar is _already_ updated. If we do not update the internal tracking of the `browserUrlTree`, we will be out of sync with the real URL if the navigation is rejected. It would be best if we could remove `browserUrlTree` completely, but doing that would require a lot more investigation and is blocked by angular#27059 because the SpyLocation used in tests does not emulate real browser behavior. fixes angular#43101 PR Close angular#43102

…ngular#41730) * Do not emit url pop on Location.go * Emit a `popstate` event before each `hashchange` to have the same behavior of the browser. * Track the url change in the internal history when calling `simulateHashChange` The changes to the router tests reflect the goals of the test. Generally when `Location.go` is used to trigger navigations, it is only relevant for `HashLocationStrategy` and verifying that the Router picks up changes from manual URL changes. To do this, we convert those calls to `simulateHashChange` instead. Manual URL bar changes to the path when not using the `HashLocationStrategy` would otherwise trigger a full page refresh so they aren't relevant to these test scenarios which assert correct behavior during the lifetime of the router. [Reference for no `popstate` on `pushState`/`replaceState`](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event) > Note that just calling history.pushState() or history.replaceState() won't trigger a popstate event. The popstate event will be triggered by doing a browser action such as a click on the back or forward button (or calling history.back() or history.forward() in JavaScript). [Reference for `popstate` before `hashChange`](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event#when_popstate_is_sent) > When the transition occurs, either due to the user triggering the browser's > "Back" button or otherwise, the popstate event is near the end of the process to transition to the new location ... > 12. If the value of state changed, the popstate event is sent to the document. > 13. Any persisted user state is restored, if the browser chooses to do so. > 14. If the original and new entry's shared the same document, but had different fragments in their URLs, send the hashchange event to the window. BREAKING CHANGE: The behavior of the `SpyLocation` used by the `RouterTestingModule` has changed to match the behavior of browsers. It no longer emits a 'popstate' event when `Location.go` is called. In addition, `simulateHashChange` now triggers _both_ a `hashchange` and a `popstate` event. Tests which use `location.go` and expect the changes to be picked up by the `Router` should likely change to `simulateHashChange` instead. Each test is different in what it attempts to assert so there is no single change that works for all tests. Each test using the `SpyLocation` to simulate browser URL changes should be evaluated on a case-by-case basis. fixes angular#27059 PR Close angular#41730

angular-automatic-lock-bot · 2021-10-03T16:06:20Z

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}

AndrewKushnir added the area: testing Issues related to Angular testing features, such as TestBed label Nov 12, 2018

ngbot bot added this to the needsTriage milestone Nov 12, 2018

vikerman added area: router type: bug/fix severity3: broken freq1: low labels Dec 5, 2018

ngbot bot modified the milestones: needsTriage, Backlog Dec 5, 2018

yggg mentioned this issue Jun 29, 2019

docs(menu): Fix selection highlight in menu service example akveo/nebular#1660

Closed

2 tasks

atscott added state: confirmed triage #1 labels Jun 4, 2020

atscott mentioned this issue Jun 4, 2020

fix(router): fix navigation ignoring logic to compare to the browser url #37408

Closed

jelbourn added P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent and removed severity3: broken labels Oct 1, 2020

aahmedayed mentioned this issue Jun 2, 2021

fix(common): synchronise location mock behavior with the navigators #41730

Closed

14 tasks

atscott mentioned this issue Aug 10, 2021

fix(router): eagerly update internal state on browser-triggered navigations #43102

Closed

atscott closed this as completed in c6a9300 Sep 2, 2021

angular-automatic-lock-bot bot locked and limited conversation to collaborators Oct 3, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Testing: inconsistencies between Location and SpyLocation #27059

Testing: inconsistencies between Location and SpyLocation #27059

robisim74 commented Nov 12, 2018

yggg commented Jun 29, 2019

ondrasej commented Jul 25, 2020

angular-automatic-lock-bot bot commented Oct 3, 2021

Testing: inconsistencies between Location and SpyLocation #27059

Testing: inconsistencies between Location and SpyLocation #27059

Comments

robisim74 commented Nov 12, 2018

🐞 bug report

Affected Package

Is this a regression?

Description

🔥 Exception or Error

🌍 Your Environment

yggg commented Jun 29, 2019

ondrasej commented Jul 25, 2020

angular-automatic-lock-bot bot commented Oct 3, 2021