👨🏫 Co-Founder of This is Learning, Organizer of AarhusJS
✍️ Writer, Speaker, FOSS Maintainer 📗 Author
🏆 Microsoft MVP 🌟 GitHub Star
🌊 Nx Champion 🦸 Angular Hero of Education
When we use the TestBed we need to emulate parts of the Angular framework such as trigger change detection. The TestBed doesn't bootstrap an Angular application. No longer are all events caught by the NgZone triggering change detection. This is also the case here. If we don't wrap Router#navigate* in NgZone#run in tests, a warning is triggered.
👨🏫 Co-Founder of This is Learning, Organizer of AarhusJS
✍️ Writer, Speaker, FOSS Maintainer 📗 Author
🏆 Microsoft MVP 🌟 GitHub Star
🌊 Nx Champion 🦸 Angular Hero of Education
👨🏫 Co-Founder of This is Learning, Organizer of AarhusJS
✍️ Writer, Speaker, FOSS Maintainer 📗 Author
🏆 Microsoft MVP 🌟 GitHub Star
🌊 Nx Champion 🦸 Angular Hero of Education
When we use the TestBed we need to emulate parts of the Angular framework such as trigger change detection. The TestBed doesn't bootstrap an Angular application. No longer are all events caught by the NgZone triggering change detection. This is also the case here. If we don't wrap
Router#navigate*
inNgZone#run
in tests, a warning is triggered.Lars, in your tests you just check whether the navigation went through or was denied, right ?
So, was triggering change detection still necessary ?
If we want to avoid warnings, yes. The warning will say that a scheduled event happened outside of the NgZone.
We also want to make sure that changes are stable as they would be in an app.